3

我对 MVC 比较陌生，并试图为基于 MVC 4 的 Web 应用程序构建一个框架。

这个问题与我的性质有些相似，但我有一个特殊情况，我希望社区评估并为我提供意见。

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

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

Web 应用程序和 API（移动应用程序）的功能重叠

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

  1. 跨 Web 应用程序和 API 重复使用视图模型以实现相同的功能（例如，更新在 Web 和移动应用程序上公开的个人的地址）是一个好主意吗？验证（例如地址验证——比如地址行、城市、州、邮编）应该放在哪里？
  2. Windows 服务功能在本质上更适合 Web+API（例如，发送提醒电子邮件的夜间作业），但可能与 Web+API 使用的“模型”部分重叠。服务直接使用“模型”还是有一个像“视图模型”这样的层是个好主意。在这种情况下，验证会去哪里？
  3. 我想了解更多信息的另一个概念性问题是 - 属性驱动验证是通过 MVC 框架实现的，即 MVC 架构采用视图模型，在视图模型属性上找到验证属性并注入相关验证. 在 API 和模型被 Windows 服务使用的情况下，这个属性驱动的验证将如何工作？
4

2 回答 2

2

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

是错误验证的最佳方法的代理问题。这可以引发一场宗教辩论。有趣的是你有没有假设另一个位置不是一个选项？

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

注意事项：

模型验证

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

查看模型检查

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

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

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

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

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

于 2013-06-02T14:03:13.890 回答
0

免责声明：我不确定正确的答案是什么，但无论如何我都会发表评论（不期望接受）。此外，这个答案没有解决 1,2 或 3。

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

数据库之前的验证用于检查数据的正确性，并在很大程度上重复了视图模型中的验证和自定义验证。有时，数据库验证有额外的检查，然后如果有一个无效的模型，错误就会穿梭回视图。它的效率很低，我希望有人提出更好的解决方案。

附加信息：这是另一个有用的提示。如果它们具有相同的属性，则可以对来自 api 或 windows 服务的对象使用视图模型验证，请参阅如何在非 ASP.net 上下文中使用 C# 中的数据验证属性？

于 2013-06-02T08:05:45.317 回答