我有一種情況,業務需求決定所有數據訪問都是通過存儲過程完成的。我選擇使用實體框架,因爲我知道存儲過程的支持在4.0中得到了很大的改進,但是,我有一組包含一些額外參數(UserName,ReasonCode等)的過程,它們將用於proc中的附加邏輯。這是一個非常常見的情況,所以我很驚訝,EF讓它難以置信地難以實現。在Entity Framework中使用帶額外參數的存儲過程的策略4
當我看到我的唯一選項解決這個越來越如下:
- 創建一個查詢基礎表數據庫中的視圖,幷包含空值額外的列名。
- 處理SaveChanges事件,或覆蓋上下文中的SaveChanges方法並手動處理函數調用。
選項1在我目前的項目中不存在問題,但它是最簡單的。
選項2是一個令人難以置信的工作量。 EF的全部重點是讓我不必編寫易於出錯的令人生厭的繁瑣數據訪問代碼。讓我們來看看這裏所涉及的工程潛在數量:
- 創建爲每個實體需要此信息的函數的進口,並在必要每次修改操作(插入,更新,刪除)
- 創建包含一些常見類型所有這些信息,並通過部分類將其應用於每個實體。
- 寫的每個方法映射功能爲每個實體(3 * N)注意,這也涉及到獲得原始值的更新和刪除
- 覆蓋SaveChanges方法來檢查每個實體,看它是否是正確的IFoo接口,檢查實體的狀態,然後調用該實體類型的適當方法。
我錯過了什麼?爲什麼這樣一個常見的情況很難執行。
我知道有人可能認爲我可以編寫一個T4模板來爲我生成所有這些代碼,但這只是讓我回到了這樣一個繁瑣的樣板代碼,它沒有增加真正的價值。有一個簡單的方法可以說:
「喲EF!我打電話給proc!我知道我在做什麼,我想在capiche中添加這些額外的值?「
爲好奇額外的信息:
- 我使用的是自跟蹤實體與WCF模板
- 附加PARAMS不存在任何地方,可以通過實體 掛
- 附加參數始終是相同的
- 存儲過程如下,它們不能從其當前合同中修改
任何對此事的幫助或見解都將非常受歡迎!
乾杯,
喬希
「我有一種情況,業務需求決定所有的數據訪問都是通過存儲的特效完成的。」 - 我很抱歉。 – StriplingWarrior 2010-11-23 17:37:57
這不是一個大問題,但是,如果我不必這樣做,那將會很好。不幸的是,設計需要這種方法。我希望它沒有,但我卡住了。如果可以的話, – Josh 2010-11-23 17:40:22