需要一些關於MVVM +輕量級對象的建議+ EF

我們開發的後臺應用程序的Db相當大。從數據庫到內存加載所有內容是不合理的，所以當模型的屬性被請求時，我們從數據庫中讀取（通過EF）但是我們的許多UI只是簡單的具有一些（！）屬性的實體列表。例如，我們只想顯示標題，標題和名稱。後來當用戶選擇該項目並想執行一些操作時，需要整個對象。現在我們有存儲在內存中的項目列表。某些屬性包含較大的文本，圖像或其他數據。 EF與實體一起工作，讀取一堆大對象會顯着降低性能。需要一些關於MVVM +輕量級對象的建議+ EF

據我所知，問題可以通過創建輕量級實體並在適當的上下文中使用它們來解決。

首先。我恐怕每個視圖都會讓我們創建新的LightweightEntity，並且我們最終會以臃腫的對象上下文結束。

二。由於模型包裝EF，我們需要爲各種實體提供方法。

三。 ViewModel相互通信並傳遞實體。

所以我堅持所有這些考慮因素，需要良好的建築設計建議。有什麼建議嗎？

來源

2012-08-03 Pavel Voronin

看看[這篇文章]（http://blogs.teamb.com/craigstuntz/2009/12/31/38500/）有幫助。 – 2012-08-03 17:38:57

@克雷格斯坦茲。不知道EF支持這一點。謝謝！而這個投影被編譯成SQL，不會返回不必要的屬性，不是嗎？ – 2012-08-03 18:27:23

是的，它被翻譯成SQL。 – 2012-08-03 19:04:18

對於圖像大文本，您可能會考慮table splitting，它通常用於在輕量實體和「重」實體中拆分表。

但我認爲你所稱的輕量級「實體」是數據傳輸對象（DTO's）。這些不是由上下文提供的（所以它不會臃腫），而是通過實體的投影，這是在存儲庫或服務中完成的。

對於投影，您可以使用AutoMapper，特別是其中描述的新功能here。這允許您減少爲「各種實體」（DTO's）提供的方法數量，因爲要投影的類型可以在泛型類型參數中給出。

來源

2012-08-03 18:09:36

不要爲此使用AutoMapper。它並沒有解決返回大型實體/在SQL中選擇太多的問題，因爲它現在不處理IQueryable 。 – 2012-08-03 19:05:11

@克雷格然而，它是非常有用的庫。 :) – 2012-08-03 19:35:34

@CraigStuntz，新的（er）功能，因爲投影傳播到SQL查詢中，所以只有投影所需的字段被查詢，而不是整個記錄（如以前那樣）。 – 2012-08-03 19:44:09

需要一些關於MVVM +輕量級對象的建議+ EF

回答

相關問題