如果您参考 Silverlight 开发的任何 MVVM 示例，您会发现每个 ViewModel 都有自己的 DomainContext。但是，我真的认为不需要 ViewModel 特定的 DomainContext。
我倾向于为所有 ViewModel 创建一个共享的 DomainContext。这样，当将实体添加到不同的 DomainContext 并从不同的 DomainContext 中删除它的问题永远不会出现。否则，您可能会尝试从根本没有该特定实体的 DomainContext 中删除，因此异常..
谁能告诉我关于 DomainContext 的最佳实践是什么？
【问题讨论】：
标签： c# silverlight c#-4.0 silverlight-4.0
我的两本关于 MVVM 的教科书，分别是...
使用 Windows® Presentation Foundation 和模型视图 ViewModel 模式构建企业应用程序，作者 Raffaele Garofalo
Pro WPF 和 Silverlight MVVM 使用 Model-View-ViewModel 进行有效的应用程序开发，作者 Gary McLean Hall
...不要直接寻址 DomainContext。然而，两位作者都同意，在涉及数据访问层的地方，推荐使用“工作单元”设计模式。如果您打算在 SL 应用程序中使用一个或多个 DomainContext(s) 作为数据访问层的一部分，那么（无论如何，这些机构都会建议您）考虑将它们封装到“工作单元”模式中。让您的 ViewModel 处理这些抽象。
至于最佳实践，我认为在认真考虑这些模式后，您已经满足了“最佳实践”。。在许多情况下，实施它们可能是矫枉过正。
http://msdn.microsoft.com/en-us/magazine/dd882510.aspx 有对“工作单元”的介绍
【讨论】：
有很多方法可以解决，所以我能做的最好的就是分享我所做的。
1) 根据功能创建每个域上下文。例如，我将为所有用户函数创建一个上下文，为所有客户函数创建一个上下文，为所有订单函数创建一个上下文，等等。这允许清晰的 BusinessLayer 细分。
2) 在 Web 项目中创建将返回的自定义类，而不是向导创建的抽象视图。我个人在将 IQueryAble 中指定的数据库视图的名称返回给 Silverlight 项目时遇到问题，因为 Silverlight 项目可以被视为 UI 层。它间接地强制依赖 DataLayer，这是我们不想要的。是的，它通过添加额外的类创建了更多的工作，但它有助于为适当的 3 层架构实施抽象。
3) 在 UI 层上创建自定义类，以消化从映射方法（来自 DataContext）返回的数据。这有助于强制执行抽象。
请记住，最终目标是使您的代码尽可能松耦合。这总是需要您进行额外的（有时是冗余的）编码，但最终结果值得付出努力。
您也可以考虑创建一个 RIA 类库；这使您可以进一步抽象。这不是最简单的实现，但在尝试促进 Silverlight 和 Web 项目之间的通信时，它是朝着正确方向迈出的一步。
【讨论】：