我正在研究一个管理行业特定输入的数据库应用程序，然后通过一些复杂的计算，查找等运行该信息，以返回一系列其他值和一个go / no-go结论。
我决定使用Entity Framework（代码优先于提供程序独立性）和WPF（MVVM模式）。我正在使用POCO实体作为我的数据模型，视图模型正在处理基本数据/业务规则验证等常见内容。
看起来EF + WPF / MVVM非常适合显示和验证输入并将其输入数据库，以便查询典型的业务应用程序，如产品，客户，订单设置。但是，根本不清楚在哪里插入“计算层”。在视图模型和数据模型（我的POCO）之间，事情已经感觉有点臃肿，现在我正面临着与其他两个非常相似的另一层。
或许最好的方法是使计算层成为一种元视图模型，并将尽可能多的验证，更改通知等推入其中，并使用更轻的实际视图模型运行。
任何人遇到这样的情况？
修改
原来我真正需要的是简化视图模型并加强实体。因此，我减轻了视图模型，将属性更改通知和基本验证移动到实体以允许直接绑定，并使计算类直接使用实体以及向实体添加一些基本例程。感谢关于ADM文章@Peter Porfy的链接。
为了使验证更接近实体，使用了Fluent Validation（优秀的建议@Gloopy！）。为了更容易在实体上实现属性更改通知，已调整this technique。为了避免在视图模型中创建无限的属性包装器（设置HasChanges属性），我使用了Josh Smith's PropertyObserver。
答案 0 :(得分：1)
MVVM代表Model-View-ViewModel，其中Model层包含 models 您实际域问题的所有内容。
所以这取决于你的意思'计算层'。
把它放在它所属的地方。
如果实际操作属于域实体，则应将该逻辑放入实体中。不要制作贫血领域模型：
Article from Martin Fowler关于ADM。
DDD与EF代码优先完美配合。
如果某些内容不属于任何实体，那么您可能应该将其作为服务公开。然后使用视图模型中的interface。
dependency injection容器可以让您的生活更轻松，但没有它就可以生活。
您没有插入另一个图层，因为它是模型图层。您的视图模型应尽可能保持精简，只需建模视图的状态并将实际业务操作转发给实体/服务类。
答案 1 :(得分：0)
我可能会创建一个接口/对象来处理计算（如果它们可以逻辑拆分，则可以创建几个）并将该对象传递到您想要使用它的任何位置。您可能会因使用依赖注入框架而受益，this post可能会对此有所帮助，因此您无需在需要的地方显式实例化对象。
同样this post提及可能不完全适用的FluentValidation.NET，但也可能有一些好的模式可供学习/在那里使用。