实体框架，MVVM和计算类

我正在处理一个数据库应用程序，该应用程序管理特定于行业的输入，然后通过稍微复杂的计算，查找等运行该信息以返回一系列其他值和一个去/不去结论。实体框架，MVVM和计算类

我决定使用实体框架（代码首先为提供者独立）和WPF（MVVM模式）。我使用POCO实体作为我的数据模型，视图模型正在处理基本数据/业务规则验证等常见问题。

看来EF + WPF/MVVM在显示和验证输入并将其输入数据库以查询典型业务应用程序（如产品，客户，订单设置）方面非常出色。但是在什么地方插入一个“计算层”还不是很清楚。在视图模型和数据模型（我的POCO）之间，事情已经感觉有点臃肿，现在我正在面对另外两层，就像另外两层一样。

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

任何人遇到这样的情况？

编辑

原来我真正需要的是瘦视图模型和牛肉起来的实体。所以我减轻了视图模型的影响，将属性更改通知和基本验证移动到实体以允许直接绑定，并使计算类直接消耗实体以及向实体添加一些基本例程。感谢ADM文章@Peter Porfy上的链接。

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

来源

2012-07-07 N Jones

MVVM代表Model-View-ViewModel，其中模型图层包含什么模型您的实际域问题。

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

把它放在它所属的地方。

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

Article from Martin Fowler。

DDD完美适用于EF代码优先。

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

A dependency injection容器可以让你的生活更轻松，但你可以没有它。

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

来源

2012-07-07 12:08:05

在阅读了ADM和DDD文章（和谷歌搜索）之后，它看起来像是扩展我的实体和创建服务类的混合体。我对扩展实体的犹豫是每个人都避开它，但也让它们更难阅读/使用。它变得不太清楚什么是数据存储中的属性，以及什么是计算属性，还有很多额外的标记，指示EF应该忽略的内容等等。我是在过度复杂还是存在一种“安全”方法来处理扩展实体？ – 2012-07-07 16:18:52

我不认为'每个人都避开它'，但是你是对的，更多的人与ADM合作。这样你就可以从一个清晰的程序化（！）风格的doman层中获益，但却失去了OOP的好处。这取决于每个人的选择，我相信它们都有它的位置。通过适当的SOLID设计（ggl），它不会不那么清晰，但更具可读性和可追踪性。 – 2012-07-07 18:21:52

总而言之，EF和其他ORM隐藏了一些事实，即应用程序的某些状态存储在数据库中，因此您可以继续使用OOP样式编码。你不应该从你的领域模型中获益。如果您不想使用属性混淆实体，则可以指定要在datacontext配置中忽略的内容。 – 2012-07-07 18:28:34

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

也this post提及FluentValidation.NET这可能不完全适用，但也可能有一些很好的模式，以及从那里学习/使用。

来源

2012-07-07 08:04:09 Gloopy

我喜欢FluentValidation项目的想法。我会考虑使用它。 – 2012-07-07 16:21:31

实体框架，MVVM和计算类

回答

相关问题