对于和Asp.Net MVC 4 Web应用程序+ API + Windows服务，什么是放置验证的正确位置 - 在模型或ViewModel上？

Question

我对MVC相对较新，并试图为基于MVC 4的Web应用程序组建一个框架。

这question与我的有点相似，但我有一个特殊的情况，我希望社区评估并为我提供输入。

我有一个软件系统，它有两个组件 - 一个MVC 4 Web应用程序和一个Windows服务。 Windows服务和Web应用程序将访问“模型”层（我指的是域表等）。

我还计划在不久的将来向移动应用程序公开大量功能，API也将使用该模型。

功能重叠将出现在Web应用程序和API（移动应用程序）

中

以下是针对我的案例的一些问题：

1. 在Web应用程序和API中重复使用View Models以获得相同的功能（例如，在Web和移动应用程序中公开的个人的更新地址）是一个好主意吗？验证（例如地址验证 - 如地址线，城市，州，邮政全部合并）应该在哪里？
2. Windows服务功能在本质上与web + API（例如发送提醒电子邮件的夜间作业）更加互补，但可能与Web + API使用的“模型”部分重叠。服务直接使用“模型”或者像“ViewModel”这样的层是一个好主意。在这种情况下验证会在哪里？
3. 我想了解更多信息的另一个概念性问题是 - 属性驱动验证是通过MVC框架实现的，即它是采用视图模型的MVC架构，在视图模型属性上找到验证属性，注入相关验证。在API的情况下以及当Windows服务使用模型时，此属性驱动验证将如何工作？

Answer 1

  

放置验证（模型或视图模型）的最佳位置？

是最佳错误验证方法的代理问题。这可以开始一场宗教辩论。有趣的是，你认为另一个地方不是一个选择吗？

要考虑的PRO和CON或要点是一个很好的起点。 但正确的选择取决于手头任务的规模和复杂程度。 例如，我希望能够重用任何频道的所有错误验证（webUI / Windows UI / WCF API等） 我想集中宣布“规则”，让它们出现在各处并进行翻译。 我想避免数据库约束作为错误检查方法。 但数据访问层验证也是该方法的一部分，以及如何使用异常处理它。 EG并发。 所以你可以看到没有简单的答案。

  

考虑：

模型验证

• 注释，例如[必需]，[StringLength（n）]
• 使用IValidatableObject
• 两者都可以由其他框架检查或触发，例如MVC，Entity Framework
• 检查直接引用对象并适合DDD。一个对象应该知道它的基本业务规则，例如，如果字段X，则Y必须.....
• 但不能轻易地进行跨对象检查，例如检查逻辑副本。
• 如果您需要“读取”其他数据以进行检查，则层分离和反转控制挑战。
• 交叉对象检查不适合模型，并且确实需要自己的图层/级别

查看模型检查

• 如何从接口继承注释。那么如何避免视图模型中注释中“规则”的重复。

• 客户端与服务器端验证的方法将推动一些设计。 客户端验证技术的选择也是重要的。 MVC注释，数据，自定义javascript框架？

• VIew模型中的某些规则适用于流程，而不适用于单个对象。 这个逻辑应该在ViewModel中吗？或业务流程层？

我个人认为核心OUT方法最好。直接在Model中声明尽可能多的规则。但也有业务流程层规则。 使用业务流程/服务层执行业务级别，跨对象检查。 如果可能的话，继承或带出中心规则而不重复。 除了简单的注释之外，还需要更多的构建工作。 例如，视图模型中的[必需]很容易完成。保持它并不难，但根据有多少型号和视图模型组合而变得混乱。 但是将Json / Ajax与从中心点拖动的自定义构建规则一起使用是另一个涉及复杂javascript和模型中某种“元”数据方法的选项。

当然，使用客户端验证可用性。

Answer 2

Disclamer： 我不确定答案是什么，但我还是会发表评论（没有期望接受）。此外，这个答案不涉及1,2或3。

在我当前的项目中，我们在视图模型和数据库端使用验证。视图模型上的验证可以向用户提供一些反馈，因为视图模型上的验证可以与不显眼的ajax一起使用，以在发布无效视图模型时提供反馈。

数据库之前的验证用于检查数据的正确性，并在视图模型中大量复制验证和自定义验证。有时，数据库验证有额外的检查，然后如果存在无效模型，则将错误传递回视图。效率很低，我希望有人提出更好的解决方案。

附加信息：这是另一个有用的暗示。如果它们具有相同的属性，则可以对来自api或windows服务的对象使用viewmodel验证，请参阅How can I use the Data Validation Attributes in C# in a non-ASP.net context?