EF（6.1）代码优先存储过程问题

Question

因此，我对EF 6.1采用了反向工程（代码优先）的方法。 我正在使用POCO生成器VS Extension从现有数据库等生成（反向工程）我的表。

在我的上下文类中，我调用了为插入，删除和更新事件连接的存储过程，这是有问题的一个：

modelBuilder.Entity<StandardAdditionalInformation>().MapToStoredProcedures(s => 
            s.Insert(u => u.HasName("standard_additionalinformation_save")
                    .Parameter(p => p.Notes, "Notes")
                    .Parameter(p => p.StandardOptout, "StandardOptout")
                    .Parameter(p => p.StandardOptoutReason, "StandardOptoutReason")
                    .Parameter(p => p.IsDeleted, "IsDeleted")
                    .Parameter(p => p.CreateDate, "CreateDate")
                    .Parameter(p => p.CreatedByAccountId, "CreatedByAccountId")
                    .Parameter(p => p.UpdateDate, "UpdateDate")
                    .Parameter(p => p.ModifiedByAccountId, "ModifiedByAccountId")
            ).Update(u => u.HasName("standard_additionalinformation_save")
                    .Parameter(p => p.StandardId, "StandardId")
                    .Parameter(p => p.ClassId, "ClassId")
                    .Parameter(p => p.Notes, "Notes")
                    .Parameter(p => p.StandardOptout, "StandardOptout")
                    .Parameter(p => p.StandardOptoutReason, "StandardOptoutReason")
                    .Parameter(p => p.IsDeleted, "IsDeleted")
                    .Parameter(p => p.CreateDate, "CreateDate")
                    .Parameter(p => p.CreatedByAccountId, "CreatedByAccountId")
                    .Parameter(p => p.UpdateDate, "UpdateDate")
                    .Parameter(p => p.ModifiedByAccountId, "ModifiedByAccountId")
            ).Delete(u => u.HasName("standard_additionalinformation_delete")
                    .Parameter(p => p.StandardId, "StandardId")
                    .Parameter(p => p.ClassId, "ClassId")
        ));

因此，基本上，调用存储的proc就像db.Set（）。Add（value）;一样简单。 //其中value是StandardAdditionalInformation对象。 db.SaveChanges（）;

对于绝大多数电话（99％），它将是一个更新。

我的问题在这里：调用更新时，出现异常：

Procedure or function standard_additionalinformation_save has too many arguments specified.

因此，在进一步研究，运行SQL跟踪等之后，我想到了这是ACTUAL更新调用：

exec [dbo].[gsp_dal_teacherclass_standard_additionalinformation_save] @StandardId=12,@ClassId=1,@Notes=N'blah',@StandardOptout=0,@StandardOptoutReason=N'',@IsDeleted=0,@CreateDate='2014-05-02 13:03:00',@CreatedByAccountId=34068,@UpdateDate='2014-05-12 10:05:04.6067328',@ModifiedByAccountId=34068,@StandardAdditionalInformation_StandardId=NULL,@StandardAdditionalInformation_ClassId=NULL

EF似乎正在向Sproc调用中注入2个参数：

@StandardAdditionalInformation_StandardId=NULL
@StandardAdditionalInformation_ClassId=NULL

这些代码未在代码“任何”中引用，但是它们是表本身上PK的值。

有什么我想念的吗？ 我的意思是，是否不应仅使用上下文构建器中定义的参数来调用存储的proc？ 我的解决方法是将这两个参数添加到sproc，并且效果很好，我只是认为这是一个非常肮脏的解决方案，并且不希望它投入生产！

Answer 1

进一步研究之后，我发现所讨论的表的PK和FK相同。 我删除了FK并修改了PK，使其与在编写此代码并繁荣起来之后对表结构进行的更改更加一致。

我想我为“解决方案”提出了这个问题：

EF是否会生成将强制使用存储过程参数的代码？ IE浏览器。 EF是否认识到PK / FK的存在并知道要寻找多对多关系，因此会注入它认为应该存在的参数？