验证逻辑应该在哪里实现?

验证规则应以抽象的方式在类级别定义,这两种方式都可以1)在类的本机环境中运行2)根据需要呈现为其他依赖环境(如UI脚本或存储库过程)的规则。

这将使您获得集中在它应该在哪里、在类中的逻辑,以及在UI和其他任何地方的辅助验证——很容易维护,因为它是从类派生的,而不是在断开连接的位置上分离逻辑。全胜。

验证逻辑应该在哪里实现?

到处都是。

• 你应该在用户界面级别进行验证,这样用户就可以得到即时的、有用的反馈(比如,填写一个webform,在它旁边有一个javascript,上面写着“密码太短”,这样你就不会有不必要的服务器访问)。
• 您应该从用户界面验证进入主软件的任何输入。永远不要信任用户界面,尤其是大型项目或网站上的用户界面-它们可能被绕过,或者由不同的团队开发。
• 您应该验证函数/方法/类的输入。这些具有与项目需求无关的固有限制(除了它能够管理所需的输入范围之外)。这里的想法是鼓励安全代码重用。以一个类为例,你知道如果超出它的参数,它会失败——如果超出了参数,它会告诉你是否失败。
• 还有许多其他需要进行验证的领域(数据库、备份/恢复、辅助通信通道等)

这看起来像是大量的工作,或者额外的开销,但事实是,有充分的理由重新验证链上的所有内容,其中最起码的一个原因是在成为问题之前捕获错误。

-亚当

我已经成功地将所有的验证都放在业务层中数据存放的地方。例如,在属性设置器中。这样可以保证您只在业务层中传递有效的数据,并保证UI将从业务层接收有效的数据。

在某种程度上,如果代码总是通过业务层,这也避免了在数据层中进行大量验证的需要。

我唯一会武断的规则是 从未 信任UI级验证,因为这一层最容易受到损害(特别是在Web应用程序中)。用户界面验证是一种甜味剂,只是为了让你的用户体验更友好。

双方之间的合同(接口),如A和B,双方都有一定的义务。合同上说什么?B是否应该接收经过验证的数据?如果是这样的话,B不应该实现验证。但是如果a是用户界面呢?显然,你不想把验证放在那里。一般来说,最好是引进第三方,比如说C.A和C有合同,而C又和B有合同,B希望得到经过验证的数据。A可能会送来垃圾。C执行验证。

如果合同设计得很好,这几乎不是问题。对合同进行修订,并对各方承担义务。如果某一方的义务太多,则引入第三方。

当然,在Web环境中,您在客户端进行验证的任何内容都可以被忽略。

通常我在课堂上进行验证。然后让setter引发或抛出异常,或者如果您喜欢使用返回值。我在.NET世界中使用异常,因为我可以有一组自定义异常,并将清晰的验证规则消息返回给使用者/客户机。

验证应该是对象的一部分。使环境成为对象构造函数参数的一部分。这样,您就可以为环境定制验证逻辑,但对象不必知道它在哪里运行。

我总是使用UI验证,即使它的安全性非常差。它节省了到服务器的往返行程(带宽确实增加了),并且允许您使用错误消息更方便地使用。但它永远不应该是唯一的验证层。