实体框架、MVVM 和计算类答案

【问题标题】：Entity Framework, MVVM, and Calculations Classes实体框架、MVVM 和计算类
【发布时间】：2012-07-07 02:46:32
【问题描述】：

我正在开发一个数据库应用程序，它管理行业特定的输入，然后通过一些复杂的计算、查找等运行该信息，以返回一系列其他值和一个通过/不通过的结论。

我决定使用实体框架（代码优先以实现提供者独立性）和 WPF（MVVM 模式）。我使用 POCO 实体作为我的数据模型，而视图模型正在处理诸如基本数据/业务规则验证之类的常规操作。

似乎 EF + WPF/MVVM 非常擅长显示和验证输入并将其输入数据库以查询您的典型业务应用程序，例如产品、客户、订单设置。但根本不清楚在哪里插入“计算层”。在视图模型和数据模型（我的 POCO）之间，事情已经有些臃肿了，现在我正面临着添加另一个层，非常像其他两个层。

也许解决此问题的最佳方法是使计算层成为一种元视图模型，并将尽可能多的验证、更改通知等推送到其中，并使用更轻量的实际视图模型运行。

有人遇到过这种情况吗？

编辑

事实证明，我真正需要的是精简视图模型并增强实体。所以我减轻了视图模型，将属性更改通知和基本验证移至实体以允许直接绑定，并使计算类直接使用实体以及向实体添加一些基本例程。感谢 @Peter Porfy 提供有关思想 ADM 文章的链接。

为了使验证更接近实体，使用了Fluent Validation（极好的建议@Gloopy！）。为了更容易在实体上实现属性更改通知，改编this technique。为了避免在视图模型中创建无穷无尽的属性包装器（设置 HasChanges 属性），我使用了Josh Smith's PropertyObserver。

【问题讨论】：

标签： entity-framework design-patterns mvvm ef-code-first

【解决方案1】：

MVVM 代表Model-View-ViewModel，其中模型层包含模拟您的实际领域问题的所有内容。

所以这取决于你的意思是“计算层”。

把它放在它所属的地方。

如果实际操作属于域实体，那么您应该将该逻辑放入实体中。不要制作贫血的领域模型：

Article from Martin Fowler 关于 ADM。

DDD 与 EF 代码优先完美配合。

如果某些东西不属于任何实体，那么您可能应该将其作为服务公开。然后通过 interface 从您的视图模型中使用它。

dependency injection 容器可以让您在这里的生活更轻松，但没有它您也可以生活。

您没有插入另一层，因为它是模型层。您的视图模型应尽可能保持精简，只需对视图的状态进行建模并将实际业务操作转发给实体/服务类。

【讨论】：

在阅读了 ADM 和 DDD 文章（和谷歌搜索）之后，似乎是扩展我的实体和创建服务类的组合是要走的路。我对扩展实体的犹豫是每个人都避开它，但它也使它们更难以阅读/使用。数据存储中的属性是什么以及计算属性是什么变得不太清楚，还有很多额外的标签指示 EF 应该忽略的内容等。我是否过于复杂，或者是否有一种“安全”的方式来处理扩展实体？跨度>
我不认为'每个人都回避它'，但你是对的，更多的人选择 ADM。这样你就可以从一个清晰的程序（！）风格的域层中受益，但会失去 OOP 的好处。这取决于每个人的选择，我相信两者都有它的位置。通过适当的 SOLID 设计（ggl it），它不会变得不那么清晰，但更具可读性和可遵循性。
所有 EF 和其他 ORM 都是为了隐藏应用程序的某些状态存储在数据库中的事实，以便您可以保持 OOP 样式编码。你不应该放弃你的领域模型的好处。如果您不想将实体与属性混淆，您也可以在 datacontext 配置中指定要忽略的内容。
不要把它想象成“扩展实体”，因为它不是扩展，而是用行为制作真正的 OOP 类。当然要考虑 SRP。但是你也可以使用 ADM，我看到了它的好处，在 OOP 中到处传递值对象是不自然的。

【解决方案2】：

我可能会创建一个接口/对象来处理计算（或多个，如果它们可以在逻辑上拆分）并将该对象传递到您想要使用它的任何地方。您可能会从使用依赖注入框架中受益，也许 this post 可以帮助您，这样您就不必在需要它们的地方显式实例化您的对象。

另外this post 提到FluentValidation.NET 可能并不完全适用，但也可能有一些很好的模式可供学习/使用。

【讨论】：

我喜欢 FluentValidation 项目的想法。我会考虑使用它。