MVC验证：在哪里验证？

Question

我们说控制器层的模型验证是验证我们将要运行的所有数据的正确位置。在这种情况下，如果我们将UI更改为另一个（记住我们的图层必须非常分离），新的数据验证原则将会执行 - 在这种情况下，我们的所有内部规则都可能被违反。 您可以说数据模型是单独的图层，而该图层（而非UI）是验证的唯一位置。但在这种情况下，我发现验证服务或业务对象层中的数据更有效，不是吗？ 实际上我们有许多对应于我们的域对象的对象：db table record，linq2sql class，domain object class，viewmodel class。它应该只是一个验证数据模型的地方吗？为什么它应该在（或接近）UI中，而不是在其他层中？在我看来，验证必须发生在服务层 - 与所有其他总线逻辑。如果我需要尽快通知用户有关错误，我将使用除主要验证之外的客户端验证。思考？谢谢。

Answer 1

数据验证是模型的责任。在我看来，放置验证规则的最佳位置是数据库中的约束。有约束条件可确保数据库中不会存储任何不正确的数据，无论它是如何访问的。不幸的是，只有基本约束适合在数据库中表达。

下一个放置验证的地方，当使用linq-to-sql进行数据访问时，我是实体类的扩展方法。然后所有代码都必须通过验证。

为了改善用户体验，可以在UI中重复基本验证，但这只是为了用户体验并尽早发现最常见的错误。在网络上，最好使用JavaScript验证。在富客户端上，有时可以重用与扩展方法调用的代码相同的代码。

永远记住，暴露给客户端的任何服务都可能被缺乏真实客户端验证的恶意客户端调用。永远不要相信客户正确地进行任何类型的验证或安全检查。

Answer 2

1.它在UI级别验证，因为减少了对服务器的额外命中。 （EnableClientSideValidation检查）。它仅用于基本验证（如无效输入等）

2.许多业务验证都写在业务层中，无论UI（WPF或MVC）如何，它们都完好无损

3.通常我们在控制器中编写UI验证，并且特定于MVC。

4.您应该按照优先顺序保留验证部分。就像有时我们在这种情况下验证实体的唯一约束我更愿意在实体本身上写我的验证属性。所以在插入数据库时​​它将被验证。

此外，您可以尝试在此处引入另一个图层（新库）以简化和解耦方法， 这个新层将执行一些验证，这些验证不是特定于UI而不是特定于业务逻辑。我们将其称为App Services Layer，它实际上也可以帮助您与WCF类似的场景进行交互。所以现在你的控制器和WCF将与同一层进行交互并进行相同的验证。

Answer 3

数据验证应该在域级别进行。但是应该捕获UI验证错误，而不必询问下游的其他人。