我正在尝试找出在 N 层 Asp.net MVC 应用程序中放置验证的位置
一方面，我觉得验证应该在业务层中与业务对象本身一起进行。这意味着当验证规则发生变化时，我只需在一处进行更改(例如，现在用户显示名称可以是任何名称，但现在我希望名称至少包含 5 个字符，并且没有符号)。这使得您可以轻松了解在哪里可以找到验证规则，并且可以更轻松地在各个流程中保持验证规则的一致性。
另一方面，我也觉得应该在 View 模型上进行验证，因为有时您需要对业务对象上不需要的特定流程数据进行验证。例如，当用户更改密码时，您希望他们在表单中输入密码两次，这样他们就不会输入密码错误而导致登录失败。您的用户业务对象不需要两个密码字段，因为它没有意义，因为更改当前密码(或创建新帐户)时只需要两个密码。因此，对我来说，对 View 模型进行验证以确保运行特定于流程的验证是有意义的。这样做的缺点是，当验证规则发生变化时，您可能有很多地方需要更新(您必须更改与用户打交道的每个 View 模型上的规则)。
第三个选项是在有意义的情况下在业务对象和 View 模型之间拆分验证。问题是我发现很难意识到验证规则是否由于 View 模型验证失败或业务对象验证失败而触发。
最佳答案
您已经做了一些很好的考虑。就我个人而言，我之前曾在 View 和 Controller 层进行过验证，但最近意识到这可能不是最好的方法。虽然在 Controller 中执行此操作确实有意义，但正如您也提到的那样，它确实可能成为一项重复性任务。
我可以保证 View 层和业务层。在向服务器发送请求之前，在 View 层中捕捉一些东西是很好的。例如，在上传 100 MB 大文件之前检查是否存在字段验证错误只是为了告诉用户他们输入错误，这是有意义的。显然， View 验证应该始终由服务器端验证支持。
被称为“胖模型”的概念在业务层中进行了尽可能多的验证，这有很多优点；
- 您的代码将是可重用的，因为它将被包装在每个业务对象中，而不是用于特定的 Controller 操作。如果您需要更新业务规则，那么您只需要更新相关模型，而不是每个使用这些模型的 Controller (您自己也对此提出了很好的观点)
- 您的代码将更具可移植性，因为例如，如果您没有依赖 Controller 来执行业务逻辑的业务层，则可以更轻松地切换到不同的框架
- Controller 将更容易理解，因此应用程序中的流程将更容易遵循，新开发人员可能会发现更容易上手
- 编写验证规则一次或两次比重复编写要少出错
- 调试和测试可能会更容易
我希望这会有所帮助。
关于validation - 验证应该针对业务模型还是 View 模型？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7530803/