Public Class Product Public Sub New(ProductID as Integer,Name as String) If ProductID > 0 AndAlso Name.Length > 5 Then _ProductID = ProductID _Name = Name Else Throw New InvalidProductException End If End Sub Private _ProductID as Integer Public Property ProductID as Integer Set(value as String) If value > 0 then _ProductID = value Else Throw New InvalidProductException End If End Set End Property 'Same principle as above for Name setter. End Class
然后我跑过Data Annotations,看起来很漂亮.我注意到大多数使用数据注释的人允许域实体暂时变为无效,然后在稍后通过调用Validate.ValidateObject来验证实体.此时,实体无效,原始状态已丢失,除非您有其他机制将其回滚.
两个问题:
1)您是否允许域名实体暂时无效?
2)根据您对#1的回答,您使用哪些技术来验证实体?
解决方法
不允许状态无效的另一个原因是在某些情况下它可能会引入ORM问题 – 我个人已经看到一个涉及NHibernate缓存和子实体的问题,这些问题无效但不知何故仍然存在于缓存中,我记不清了但任何具体细节.
我倾向于使用的技术基于验证规则和验证结果.简而言之,实体上的大多数方法都是以下面的方式实现的(C#,如果你不介意的话):
public virtual void ChangeClaimEventDate(DateTimeOffset newDate) { var operationResult = ValidatorOf<Claim> .Validate() .WithCriticalRuleOf<EventDateFallsIntoPolicyCoverage>().WithParam(newDate) .WithCriticalRuleOf<EventDateFallsIntoInsuredCoverage>().WithParam(newDate) .WithCriticalRuleOf<PerformedServicesAreAvailableOnEventDate>().WithParam(newDate) .WithCriticalRuleOf<EventDateCannotBeChangedForBilledClaim>().WithParam(newDate) .ForOperation(this); if (operationResult.OperationFailed) { throw new InvalidBusinessOperation(operationResult); } SomeDate = newDate; }
关于此代码最重要的是,甚至在实体更改之前就会检查某些验证规则.此示例显示了结果集的使用情况,因为我经常需要提供有关验证的信息,即使它成功(换句话说,我的验证失败并且必须向用户显示有关它的信息;但域实体仍然有效.
OperationResultSet和ValidatorOf是非常简单的基础结构类,允许使用流畅的接口轻松添加新的验证器.验证器实现为实现IValidator接口的类,它允许实现非常复杂的验证规则,并且更容易单独测试它们.
我的观点是,应该在对域实体进行更改之前执行验证 – 使用正确的约定和一些基础结构,它甚至可以简化代码结构.
编辑注释:由于这个答案的一些批评声音,我决定将示例代码更改为抛出异常而不是返回结果的代码.虽然我仍然认为这是采用我的方案的方法,但我同意,如果不指定完整的上下文,这可能会产生误导 – 例外确实应该是第一种选择,并且应该有其他因素来选择替代方案.
原文地址:https://www.jb51.cc/html/223889.html
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。