业务对象或实体应该自我validation吗？
Business Objects的validation是一个常见问题，但有一些解决方案可以解决这个问题。
其中一个解决方案是使用独立的NHibernate.Validator框架，这是一个基于属性的validation框架。
但我正面临着概念上的担忧。 像NH.Validator这样的属性validation器很棒，但只有在Session中的save-update-delete时才会执行validation。
所以我想知道业务对象是否不应该自我validation以保持自己的完整性和一致性？
恕我直言 – 业务对象（BO）/实体有效需要两步validation：
步骤1：BO /实体自我validation – 在此，我们仅检查实体在其状态F中是否有效。例如：如果设置了邮政编码，那么它是否具有有效字符并且具有有效长度等formsBO /实体级别validation。 但是超出此validation级别，我们无法说明BO / Entity在您的业务域和/或存储库中是有效的。 通常，BO / Entity将能够强制执行此级别的validation。
第二步：上下文validation – 在这里，我们需要validationBO / Entity是否在存储它的存储库的上下文中是有效的。 F.Ex。：邮政编码是否适用于下订单/发送订单的国家等。对于此validation，当前上下文中的某些或所有实体可能需要参与以确保BO /实体是有效。
因此，为了使实体保持纯净，您需要将validation拆分为这两个步骤 – 一个由实体本身执行，另一个由存储器执行，该存储库是持久/使用实体的。
HTH。
尽管如此，他们并不总是可以进行自我validation。 如果您输入“无效”邮政编码怎么办？ 您可以validation邮政编码需要采用特定格式，但如果您希望它们“有效”，即“存在并匹配城市”，该怎么办？ 或者，如果您只接受来自特定区号的电话号码，并且有效代码列表位于法律部门维护的数据库中，该怎么办？
如果您可以执行语义validation，那很好，可以进入业务类。 但通常情况下，您可能需要额外的validation，这些validation根本无法由业务类本身处理，但需要由与数据库和其他外部服务进行通信的类来处理。
我不知道我们是否在谈论同样的想法，但如果我们是，我喜欢你的解释。 很快，我会解释我为解决这个问题所做的工作。 在我的例子中，我的域层中的所有bussines对象必须覆盖两个方法：
显然，为了保持这一点，我有更多的课程涉及，但我不会写在这里，因为我只是试图解释这个概念
List notPassedValidationRules = new List (); //... public override void ValidateErrorsWhenSaving(Validator validator) { //... } public override void ValidateErrorsWhenDelete(Validator validator) { //... } 在这些方法中，我检查一些布尔条件，保留一组未通过的规则。 在我的例子中，在我的工作单元提交更改（插入新实体，更新，删除）之前调用这些方法，并在提交之前向用户显示可能的错误。