EF (6.1) Code-First存储过程问题

Question

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

在我的context类中，我为Insert、Delete和Update事件连接了对存储过程的调用，这就是问题所在：

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跟踪等之后，我想出了实际的更新调用：

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调用中注入了两个参数：

@StandardAdditionalInformation_StandardId=NULL
@StandardAdditionalInformation_ClassId=NULL

这些值不会在代码中引用，但是它们是表本身上的PK的值。

我是不是漏掉了什么？我的意思是，是否应该只使用上下文构建器中定义的参数来调用存储的proc？我的工作是将这两个参数添加到存储过程中，这很好用，我只是认为这是一个非常糟糕的解决方案，不想让它被刺激！

Answer 1

深入研究后，我发现有问题的表有一个相同的PK和FK。我删除了FK，并修改了PK，使其更符合在编写此代码后对表结构所做的一些更改，然后它就可以工作了。

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

EF是否生成强制存储过程参数的代码？即。EF是否识别PK/FK的存在，并知道寻找多对多关系，因此它注入了它认为应该存在的参数？