validation - 验证应该针对业务模型还是 View 模型？

Question

我试图找出在我的 N 层 Asp.net MVC 应用程序中放置验证的位置

一方面，我觉得验证应该在业务层与业务对象本身一起进行。这意味着当验证规则更改时，我只需要在一个地方更改它(例如，现在用户显示名称可以是任何内容，但现在我希望名称至少为 5 个字符且没有符号)。这使得了解在哪里可以找到验证规则变得简单，并且可以更轻松地跨流程保持验证规则的一致性。

另一方面，我也觉得验证应该在 View 模型上进行，因为有时您需要对业务对象上不需要的特定流程数据进行验证。例如，当用户更改他们的密码时，您希望他们在表单中输入密码两次，这样他们就不会在密码中出错而导致登录失败。您的 User 业务对象不需要两个密码字段，因为它没有意义，因为在更改当前密码(或创建新帐户)时您只需要两个密码。因此，对我来说对 View 模型进行验证以确保运行特定于流程的验证是有意义的。这样做的缺点是现在当验证规则发生变化时，您可能会有许多需要更新的地方(您必须更改与用户打交道的每个 View 模型上的规则)。

第 3 个选项是在您的业务对象和 View 模型之间在有意义的地方拆分验证。问题是我发现很难意识到验证规则是否由于 View 模型验证失败或业务对象验证失败而触发。

Answer 1

你已经做了一些很好的考虑。就我个人而言，我之前已经在 View 层和 Controller 层进行了验证，但最近意识到这可能不是最好的方法。虽然在 Controller 中执行此操作确实有意义，但正如您也提到的，它确实可以成为一项重复性任务。

我保证 View 和业务层。在向服务器发送请求之前，在 View 层中捕获一些东西是很好的。例如，在上传 100 MB 大文件之前检查是否存在字段验证错误只是为了告诉用户他们打错了。显然， View 验证应始终由服务器端验证支持。

被称为“胖模型”的概念将尽可能多的验证放在业务层中，这有很多优点；

您的代码将是可重用的，因为它将被包装在每个业务对象中，而不是用于特定的 Controller 操作。如果您需要更新业务规则，那么您只需要更新相关模型，而不是每个使用这些模型的 Controller (您自己也对此提出了很好的观点)

您的代码将更具可移植性，因为更容易切换到不同的框架，例如，如果您没有依赖 Controller 来执行业务逻辑的业务层

Controller 将更容易理解，因此为什么您的应用程序中的流程更容易遵循，并且新开​​发人员可能会发现更容易上手

一次或两次编写验证规则比重复编写更少的错误电话

调试和测试可能更容易

我希望这有帮助。