我们说控制器层的模型验证是验证我们要操作的所有数据的正确位置。在这种情况下，如果我们将 UI 更改为另一个（记住我们的层必须完全解耦），新的数据验证原则将执行 - 在这种情况下，我们所有的内部规则都可能被违反。 您可能会说数据模型是单独的层，该层（而不是 UI）是唯一进行验证的位置。但在这种情况下，我发现验证服务或业务对象层中的数据更有效，不是吗？ 事实上我们有很多与我们的领域对象相对应的对象：db表记录、linq2sql类、领域对象类、viewmodel类。它应该只是一个验证数据模型的地方吗？为什么它应该在（或靠近）UI 中而不是在其他层中？在我看来，验证必须发生在服务层 - 以及所有其他业务逻辑。如果我需要尽快通知用户错误，除了主要验证之外，我还将使用客户端验证。
想法？
数据验证是模型的责任。我认为放置验证规则的最佳位置是作为数据库中的约束。具有约束可以确保无论如何访问数据，数据库中都不会存储不正确的数据。不幸的是，只有基本约束适合在数据库中表达。
下一个放置验证的地方，当使用 linq-to-sql 进行数据访问时，我是实体类上的扩展方法。然后所有代码都必须通过验证。
为了提高用户体验，可以在 UI 中重复进行基本验证，但这只是为了用户体验并及早发现最常见的错误。在网络上，最好使用 JavaScript 验证。在富客户端上，有时可以重用与扩展方法调用的代码相同的代码。
永远记住，暴露给客户端的任何服务都可能被缺乏真实客户端验证的恶意客户端调用。永远不要相信客户端会正确执行任何类型的验证或安全检查。
1.在UI层面进行验证，是为了减少对服务器的一次额外打击。 （启用ClientSideValidation 检查）。它仅用于基本验证（例如无效输入等）
2.许多业务验证都是在业务层编写的，无论 UI（WPF 或 MVC）如何，它们都完好无损
3.通常我们在控制器中编写UI验证，并且特定于MVC。
4.您应该按照偏好保留验证部分。就像有时我们验证实体的唯一约束一样，在这种情况下，我更愿意在实体本身上编写我的验证属性。因此，在插入数据库时，它将被验证。
您还可以尝试在这里引入另一层（新库）以实现简单性和解耦方法， 这个新层将执行一些不特定于 UI 且不特定于业务逻辑的验证。我们将其称为应用程序服务层，它实际上还可以帮助您与类似 WCF 的场景进行交互。因此，现在您的控制器和 WCF 将与同一层进行交互并进行相同的验证。
数据验证应该在域级别进行。但是 UI 验证错误应该被捕获，而不必询问下游的其他人。