业务对象或实体应该自我验证吗?

Yoa*_*. B 7 c# validation domain-driven-design

Business Objects的验证是一个常见问题,但有一些解决方案可以解决这个问题.

其中一个解决方案是使用独立的NHibernate.Validator框架,这是一个基于属性的验证框架.

但我正面临着概念上的担忧.像NH.Validator这样的属性验证器很棒,但只有在Session中的save-update-delete时才会执行验证.

所以我想知道业务对象是否不应该自我验证以保持自己的完整性和一致性?

Sun*_*nny 10

恕我直言 - 业务对象(BO)/实体有效需要两步验证:

步骤1:BO /实体自我验证 - 在此,我们仅检查实体在其状态F中是否有效.例如:如果设置了邮政编码,那么它是否具有有效字符并且具有有效长度等形式BO /实体级别验证.但超出此验证级别,我们无法说明BO/Entity在您的业务域和/或存储库中是有效的.通常,BO/Entity将能够强制执行此级别的验证.

第2步:上下文验证 - 在这里,我们需要验证BO/Entity是否在存储库的存储库的上下文中是有效的.F.Ex.:邮政编码是否适用于下订单/发送订单的国家等.对于此验证,当前上下文中的某些或所有实体可能需要参与以确保BO /实体是有效.

因此,为了使实体保持纯净,您需要将验证拆分为这两个步骤 - 一个由实体本身执行,另一个由存储器执行,该存储库是持久/与实体一起工作的.

HTH.


Mic*_*tum 6

尽管如此,他们并不总是可以进行自我验证.如果您输入"无效"邮政编码怎么办?您可以验证邮政编码需要采用特定格式,但如果您希望它们"有效",即"存在并匹配城市",该怎么办?或者,如果您只接受来自特定区号的电话号码,并且有效代码列表位于法律部门维护的数据库中,该怎么办?

如果您可以执行语义验证,那很好,可以进入业务类.但通常,您可能需要额外的验证,这些验证根本无法由业务类本身处理,但需要由与数据库和其他外部服务进行通信的类来处理.

  • 我同意.我更喜欢将我的验证逻辑与业务实体分开. (2认同)