如果您參考開發的Silverlight的MVVM示例，您會發現每個ViewModel都有它自己的DomainContext。不過，我並不認爲需要具有ViewModel特定的DomainContext。創建RIA服務的最佳實踐DomainContext
我傾向於爲所有ViewModel創建一個共享的DomainContext。這樣當將實體添加到不同的DomainContext並從不同的DomainContext中刪除它的問題永遠不會發生。否則，它可能發生，你正試圖從沒有在所有的特定實體等異常的DomainContext刪除..
任何人能告訴我什麼是最好的做法，說的DomainContext？
我的兩本教科書上的MVVM，這是...
構建企業應用程序與Windows Presentation Foundation中和拉斐爾加羅法洛
臨WPF和Silverlight MVVM有效應用模型 - 視圖 - 視圖模型模式與模型 - 視圖 - 視圖模型由加里麥克萊恩廳
...開發不直接處理的DomainContext。然而，兩位作者都認爲，在涉及數據訪問層的情況下，建議使用「工作單元」設計模式。如果您考慮在SL應用程序中使用一個或多個DomainContext作爲您的數據訪問層的一部分，那麼您會被建議（無論如何由這些權威機構）考慮將它們封裝到「工作單元」模式中。讓你的ViewModel處理這些抽象。
至於最佳做法，我想你已經滿足了「最佳實踐」，當這些模式一直努力考慮。在許多情況下實施它們可能是矯枉過正的。
有一個'工作單位'介紹在http://msdn.microsoft.com/en-us/magazine/dd882510.aspx
有很多方法去了解它，所以我能做的最好的是股票我做什麼。
1）根據函數創建每個域上下文。例如，我將爲所有用戶功能設定一個上下文，一個用於所有客戶功能，一個用於訂單功能等。這允許清理BusinessLayer分段。
2）創建將返回，而不是由嚮導創建的抽象看法Web項目自定義類。由於Silverlight項目可被視爲UI層，因此我個人遇到了將IQueryAble中指定的數據庫視圖的名稱返回給Silverlight項目的問題。它強制間接依賴DataLayer，這是我們不想要的。是的，它增加了額外的類創建了更多的工作，但它有助於強化抽象以適合3層架構。
3）創建消化從映射方法返回的數據（從DataContext的UI層上的自定義類）。這有助於強制抽象。
記住，最終目標是使你的代碼鬆耦合越好。這總是需要額外的（有時是冗餘的）編碼，但最終的結果值得努力。
你也可以考慮創建一個RIA類庫;這可以讓你進一步抽象。這不是最簡單的實現，但是當試圖促進Silverlight和Web Projects之間的通信時，這是朝正確方向邁出的一步。