ASP.NET MVC ViewModel 验证和单一职责原则答案

【问题标题】：ASP.NET MVC ViewModel validation and Single Responsibility Principle [closed]ASP.NET MVC ViewModel 验证和单一职责原则
【发布时间】：2016-06-15 10:27:16
【问题描述】：

当谈到 MVC 中的验证时，我在在线示例中看到的最常见的方法是使用 ViewModel 来验证数据。人们要么使用数据注解，要么实现 IValidatableObject 和 IClientValidatable 接口。但这不违反单一职责原则吗？ ViewModel 真的应该负责验证吗？

我想到的一种方法是创建一个单独的验证器类并从控制器传递 ModelState 字典。这种方法的缺点是我们无法通过实现 IClientValidatable 接口和使用 JQuery 验证库来执行简单的客户端验证。

在不违反 SOLID 原则的情况下，在 MVC 中实现 ViewModel 验证的正确方法是什么？

【问题讨论】：

有两个级别的验证。一个简单的形式验证，您可以在客户端实现或在服务器上使用数据注释。然后是成本高昂的业务验证，涉及对其他数据/其他系统的多个依赖项。我想通常没有“非此即彼”，而是你需要两者。

标签： c# asp.net-mvc validation asp.net-mvc-viewmodel

【解决方案1】：

可以创建自定义验证属性。在实现一些 JavaScript 代码的 sn-ps 时，您仍然可以实现 unobtrusive client side validation。在您的自定义属性中，您可以注入您的验证器类实例。

也就是说，我认为只在 View(-Model) 中确保简单的验证规则（必填字段、长度等）是可以的。在this (old and now mainly obsolete) blog entrySteve 中，将验证阶段描述为“连续范围”，其中规则被连续执行。您可以从该条目中获取一些想法。希望对您有所帮助。

【讨论】：

【解决方案2】：

我觉得还好。一个类知道是什么使它成为一个有效的类应该是完全可以的。而且它的实现也非常灵活和合理。

当我们应用任何设计思想时，总会有取舍。以 最纯粹的形式实现它们有时可能不可行，有时可能会导致过度设计的代码带有自身的约束。

以单一职责原则为例，在书本上看起来很简单，但理解和定义什么是单一职责确实是一项任务。对于某些人来说，与 DB 的沟通可能是 SR，但您知道不仅如此，当我们进行更多练习时，还有更多责任。另一方面，如果我们以最纯粹的形式使用主体，则类中可能只有一个方法。

因此，对于大多数解决方案，我个人喜欢将琴弦拉紧，使其刚好适合那段旋律。某处合理地处于平衡状态。

【讨论】：