在哪里保持验证逻辑

好的，我已经看到关于此的其他帖子，但没有真正明确回答我的问题。在哪里保持验证逻辑

在应用程序中应该验证逻辑的位置？

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

我想到一个抽象类和两个具体类的全部和部分产品验证器，每个验证器都有自己的验证逻辑包含在类级别。

我有这样的感觉，但必须有更好的模式 - 任何建议？

来源

2010-09-05 Bob

请注意，验证不限于单场验证。验证有很多级别，第一次在字段验证之后是记录/对象验证规则，其中字段被认为是相互关联的。那么你很可能会遇到这样的情况：当你改变FieldA时，即使它没有被改变，FieldB也是无效的。一个（做作的）例子就是将某人的年龄改为低于法定驾驶限制。如果你还有一个领域给出他们的驾驶证号码，如果该字段有实际价值，现在将是完全不合逻辑的 – 2010-09-06 06:29:31

在应用程序中应该验证逻辑是什么？

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

因此，当一个新产品被插入，那么所有字段都必须验证

是。

但是当现有产品正在更新则只有场更新需要验证即也许只是descirption被被这样只有场应验证更新。

你不可能预知哪一个确切的部分将被更新。所以，您需要为所有字段（数据库的列）编写验证器。

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

来源

2010-09-05 21:42:59 dirkgently

我会知道它的一部分或整个产品作为我的验证器是否会通过一组字段进行验证。如果产品ID存在于系统中，那么我们相当正确地认为，我们正在处理更新，而不是插入。因此，根据产品是否存在，我有两条路径。这是我的第一次检查。因此，我是否应该创建一个验证该字段的每个字段的方法，然后每个验证器类（部分和整体）都可以拥有自己的逻辑来调用其所需的方法？ – Bob 2010-09-05 21:48:08

@Bob：从_insert_区分_update_很容易。有时候我曾经研究过基于SOA的WebService，并且有这个确切的问题需要解决。我所做的就是为每个领域添加验证器（而不是为每个领域分派一个类，因为这些领域主要是标量/平凡类型）。查询创建逻辑（将字段连接到SQL语句）自动调用验证。另外请注意，我会推荐使用现有的验证器，而不是自己的。但是，如果你想自己学习白名单/黑名单。 – dirkgently 2010-09-05 21:55:50

验证更新时，如何处理大量的条件语句，以确认哪些字段正在更新以及哪些字段未更新？或者你只是接受这将会发生更新？ – Bob 2010-09-05 21:58:34

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

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

来源

2010-09-05 21:39:57

有几个地方，你可以和应该做的验证，因为有不同程度的有效性：

在客户端，这需要能够在切换出UI控制的检查领域;应该检查需要匹配日期的正则表达式（如“yyyy-MM-dd”）的字符串。在Web UI上，这通常使用JavaScript完成。
在服务器端，当输入参数绑定时应检查对象的有效性。
有效的对象在处理时仍然需要检查“业务有效性”（例如，“用信用卡支付时需要有效的信用卡号码”）。

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

来源

2010-09-05 21:52:12 duffymo

在哪里保持验证逻辑

回答

相关问题