1

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

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

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

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

有人遇到过这样的情况吗？

编辑

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

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

4

2 回答 2

1

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

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

把它放在它所属的地方。

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

Martin Fowler关于 ADM 的文章。

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

如果某些东西不属于任何实体，那么您可能应该将其作为服务公开。然后通过interface.

依赖注入容器可以让你的生活更轻松，但你可以没有它。

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

于 2012-07-07T12:08:05.833 回答
0

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

这篇文章还提到了 FluentValidation.NET，它可能并不完全适用，但也可能有一些好的模式可以从中学习/使用。

于 2012-07-07T08:04:09.513 回答