表单验证和业务验证是否过多？

Question

我有关于表单验证和业务验证的问题。 我看到很多使用某种表单验证库的框架。您提交了一些值，库会验证表单中的值。如果不行，它将在您的屏幕上显示一些错误。如果全部计划，则将值设置为域对象。这里的值将是或者，更好的说，应该再次验证。很可能在验证库中进行相同的验证。我知道2个PHP框架具有这种结构Zend / Kohana。

当我看到编程和一些原则，如Don't Repeat Yourself（DRY）和single responsibility principle（SRP） 这不是一个好方法。如你所见，它验证了两次。 为什么不创建进行实际验证的域对象。

示例：包含用户名和电子邮件的表单 表格已提交。用户名字段和电子邮件字段的值将填充在2个不同的域对象中：用户名和电子邮件

class Username {}
class Email {}

这些对象验证其数据，如果无效则抛出异常。 你同意吗？您如何看待这种方法？有没有更好的方法来实现验证？ 我对很多处理这些东西的框架/开发人员感到困惑。他们都错了还是我错过了一点？

编辑： 我知道还应该有客户端类的验证。在我的观点中，这是一个不同的球赛。如果您对此有一些评论以及处理此类内容的方法，请提供。

Answer 1

• 表单验证（客户端）实际上只是为了实用性
• 业务验证是真正的验证

您的应用程序可能在没有您称之为表单验证的情况下工作，它对用户来说看起来不太好。但是，需要进行业务验证以防止数据损坏。

Answer 2

虽然DRY原则似乎正在被违反，但实际上您正在验证两个不同层次的数据 - 演示和业务;验证问题可能在这两个层之间有所不同。 在您的表示层中，您可能会关注与您的视图相关的特定元素，即在Web应用程序中，您可能需要返回包含html div的特定验证消息，以便您可以正确呈现ajax响应。

表单通常还包含与持久性相关的约束，例如没有某个表单字段为空或限制字段大小，而业务约束可能更广泛，即验证电子商务webapp中的个人是否可以通过电子商务webapp进行购买验证他过去的成功购买。

也就是说，有一些框架，例如hibernate验证器（在java上），它允许您在业务实体中包含验证元数据，这些元数据在持久化之前或在您调用其API以手动执行时进行检查。有了它，您可以在一个地方验证所有约束。

Answer 3

您所描述的方法对我来说有点过度设计。我可以看到它理论上整洁干净但在我看来，在实际情况下映射到数据会有点过于细微，造成不必要的开销和很多类在很大的方案中做的很少。的东西。当我遇到这样的事情时，它往往会开始闻到一点解决方案蔓延。此外，如果你有很多基于原语的每个字段的包装器，那么你的“AddressLine1”类和你的“AddressLine2”类之间的DRY违规几率很大，或者是一个过度复杂的继承层，这是避免它们所必需的。 / p>

这就像第六种普通形式 - 它在理论上很有意思，但是如果你以这种方式编写代码，那么你需要很长时间才能完成所有工作并且维护将成为一场噩梦。

Answer 4

如果您使用业务域对象来验证表单，这可以使用相当简单的工具来实现，这消除了大多数基于验证器的解决方案。在某种程度上，您希望将部分行为从业务域推断到表单域;这应该减少代码并改善维护，但需要额外的布线。我同意罗伯特的观点。我觉得这种方法比Zend / Cake / Ci等更好。它似乎走向了裸体对象哲学的方向;只需转储V和C，只去模型：http://en.wikipedia.org/wiki/Naked_objects

Answer 5

在网络上，您可能需要某种客户端验证作为“第一门” - 检查所需的值和其他简单的验证规则，而无需用户执行Web请求只是为了查看数据是否为'有效。最重要的是，您需要一个服务器端验证层（内置于您的域对象，服务层或其他位置），以执行对象属性和其他业务规则的实际验证。
但请注意，依赖于域的验证规则（例如，Name具有必需的属性FirstName和LastName）和纯业务规则（例如，如果State已提供，Country必须USA）不一定必须在同一个地方。

Answer 6

在 IS 的地方进行验证是多余但必要的。您需要在客户端上进行验证，以便您的用户获得更好的UI体验。它还可以减少服务器的负载。您还必须在服务器端进行验证，因为您的应用程序应该信任来自网络的任何内容。