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的存在並知道要尋找多對多關系，因此會注入它認為應該存在的參數？