我正在开发一个数据库应用程序，该应用程序管理特定于行业的输入，然后通过一些复杂的计算、查找等运行该信息，以返回一系列其他值和一个通过/不通过的结论。
我决定使用 Entity Framework (代码优先用于提供程序独立性)和 WPF(MVVM 模式)。我使用 POCO 实体作为我的数据模型，而 View 模型正在处理诸如基本数据/业务规则验证之类的常规操作。
似乎 EF + WPF/MVVM 非常擅长显示和验证输入并将其输入数据库以查询您的典型业务应用程序，例如产品、客户、订单设置。但根本不清楚在哪里插入“计算层”。在 View 模型和数据模型(我的 POCO)之间，事情已经有点臃肿了，现在我正面临着添加另一个层，就像其他两个层一样。
也许解决这个问题的最好方法是使计算层成为一种元 View 模型，并将尽可能多的验证、更改通知等推送到它们中，并使用更轻的实际 View 模型运行。
有人遇到过这样的情况吗？
编辑
事实证明，我真正需要的是精简 View 模型并增强实体。所以我减轻了 View 模型，将属性更改通知和基本验证移至实体以允许直接绑定(bind)，并使计算类直接使用实体以及向实体添加一些基本例程。感谢思想 ADM 文章 @Peter Porfy 的链接。
为了使验证更接近实体，使用 Fluent Validation (很好的建议@Gloopy!)。为了更容易在实体上实现属性更改通知，改编 this technique .为了避免在 View 模型中创建无穷无尽的属性包装器(设置 HasChanges 属性)，我使用了 Josh Smith's PropertyObserver .
最佳答案
MVVM 代表 Model-View-ViewModel ，其中模型层包含模拟您的实际领域问题的所有内容。
所以这取决于你的意思是“计算层”。
把它放在它所属的地方。
如果实际操作属于域实体，那么您应该将该逻辑放入实体中。不要制作贫血的域模型:
Article from Martin Fowler关于 ADM。
DDD与 EF 代码优先完美配合。
如果某些东西不属于任何实体，那么您可能应该将其作为服务公开。然后通过 interface 从您的 View 模型中使用它.
一个 dependency injection容器可以让你在这里的生活更轻松，但没有它你也可以生活。
您没有插入另一层，因为它是模型层。您的 View 模型应尽可能保持精简，只需对 View 的状态进行建模并将实际业务操作转发给实体/服务类。
关于entity-framework - Entity Framework 、MVVM 和计算类，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11371868/