假設我們使用DTO對象在服務層和表示層(MVC)之間傳輸數據。在這種情況下,表示層只能訪問DTO對象。因此我們不能在Entity框架中使用延遲加載功能。 我就在這裏嗎?請給出你的建議。實體框架延遲加載和DTO模式
(我DTO是不是EF實體和我已經實現工作模式的存儲庫和單位)
假設我們使用DTO對象在服務層和表示層(MVC)之間傳輸數據。在這種情況下,表示層只能訪問DTO對象。因此我們不能在Entity框架中使用延遲加載功能。 我就在這裏嗎?請給出你的建議。實體框架延遲加載和DTO模式
(我DTO是不是EF實體和我已經實現工作模式的存儲庫和單位)
您可以使用延遲加載,但只能在服務端使用延遲加載時使用附加實體。
首先把你定義的權利:你們的DTO也反對您的實體EF 4.1嗎?他們(也)是你的模型嗎?他們是否包含業務邏輯?
如果是這樣,我會建議關閉代理創建(myDbContext.Configuration.ProxyCreationEnabled = false;),因爲他們不能被序列化容易。然後使用dataAccess的存儲庫,在CRUD方法中,您指定了正確的實體狀態,如:http://blogs.msdn.com/b/adonet/archive/2011/01/29/using-dbcontext-in-ef-feature-ctp5-part-4-add-attach-and-entity-states.aspx
我的DTO不是EF中的實體,我已經實現了存儲庫和工作單元模式 –
那麼,在實體框架中使用DTO模式很好嗎?因爲我們需要使用'Include'方法加載導航屬性? –
如果您事先知道要將數據傳遞給DTO,則應避免延遲加載,因爲它可能導致許多不必要的數據庫往返。 –