我正在编写一个基于MVVM的VB.NET
Winforms项目(使用Winforms绑定).我的直觉是永远不允许域实体处于无效状态.这要求我在构造函数中为新实体和现有实体的每个setter中进行验证检查：
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接口的类,它允许实现非常复杂的验证规则,并且更容易单独测试它们.
我的观点是,应该在对域实体进行更改之前执行验证 – 使用正确的约定和一些基础结构,它甚至可以简化代码结构.
编辑注释：由于这个答案的一些批评声音,我决定将示例代码更改为抛出异常而不是返回结果的代码.虽然我仍然认为这是采用我的方案的方法,但我同意,如果不指定完整的上下文,这可能会产生误导 – 例外确实应该是第一种选择,并且应该有其他因素来选择替代方案.
