在哪里保持验证逻辑

Question

好的，我已经看过其他有关此事的帖子，但没有一个真正具体回答我的问题。

应用程序应该在哪里验证逻辑？

我有一个小应用程序，允许将新产品插入到应用程序数据库中。存在具有不同领域的不同产品，即产品名称，订单号，描述等。可以插入新产品并且可以更新现有产品。因此，当插入新产品时，必须验证所有字段，但是当更新现有产品时，只需要验证正在更新的字段，即可能只是更新了描述，因此只应验证该字段。

我正在考虑一个抽象类和两个用于完整和部分产品验证器的具体类，每个类都有自己的验证逻辑包含在类级别。

我觉得必须有一个更好的模式 - 任何建议吗？

Answer 1

假设您正在为项目使用MVC模式，验证逻辑将属于模型。如果您正在处理n层项目，请将验证逻辑放在业务层中，并确保在没有事先验证的情况下不能编写任何实体。

但我总是会验证整个对象。对已经改变的内容进行排序并仅对其进行验证似乎有点过分。当然，除非你确切地知道（通过测量）这将是一个性能问题。

Answer 2

  

应用程序应该在哪里验证逻辑？

取决于您的架构。验证可以分多个阶段处理，以实现响应。通常，尽管模型/控制器在给定的MVC架构中似乎是一个好地方。这个问题早在Joel's old forum in context of the MVC architecture就出现了。模型应该负责接受/拒绝输入似乎是合理的。

  

因此，当新产品出现时   然后插入所有字段必须   验证

是

  

但是当现有产品时   正在更新，然后只更新字段   正在更新需要进行验证   也许只是说明了   正在更新，只有那个领域   应该验证。

您无法预测哪些确切的部分会更新。因此，您需要为所有字段（数据库的列）编写验证器。

您可以简化生活并拥有一个验证器类（除非当然验证一组特定的属性太复杂/耗时）。

Answer 3

有几个地方你可以而且应该进行验证，因为有不同的有效性水平：

1. 在客户端，可以在选择UI控件时检查所需的字段;应检查需要匹配正则表达式的字符串，例如日期的“yyyy-MM-dd”。在Web UI上，通常使用JavaScript完成。
2. 在服务器端，应检查对象的有效性，因为绑定了输入参数。
3. 有效的对象在处理时仍需检查“业务有效性”（例如，“使用信用卡付款时需要有效的信用卡号码”）。

您应该同时进行客户端和服务器端验证。当输入绑定到对象时，绑定和验证由服务层完成。在处理用例时，他们还会检查业务规则。