DDD分层架构之领域实体(验证篇)

DDD分层架构之领域实体(验证篇)

 在应用程序框架实战十四:DDD分层架构之领域实体(基础篇)一文中,我介绍了领域实体的基础,包括标识、相等性比较、输出实体状态等。本文将介绍领域实体的一个核心内容——验证,它是应用程序健壮性的基石。为了完成领域实体的验证,我们在前面已经准备好了验证公共操作类异常公共操作类

  .Net提供的DataAnnotations验证方法非常强大,Mvc会自动将DataAnnotations特性转换为客户端Js验证,从而提升了用户体验。但是客户端验证是靠不住的,因为很容易绕开界面向服务端提交数据,所以服务端必须重新验证。换句话说,服务端验证才是必须的,客户端验证只是为了提升用户体验而已。

  为了在服务端能够进行验证,Mvc提供了ModelState.IsValid。

DDD分层架构之领域实体(验证篇)
[HttpPost]
public ActionResult 方法名( 实体名 model ) {
if ( ModelState.IsValid == false ) {
//验证失败就返回,可能会添加错误消息,也可能要转换为客户端能识别的消息格式
}
//验证成功就执行后面的代码
}
DDD分层架构之领域实体(验证篇)

  在控制器里写if ( ModelState.IsValid == false )判断有几个问题,下面进行一些讨论。

  第一,可能误导初学者,导致分层不清。

  从分层架构的角度来讲,验证属于业务层,在DDD分层架构就是领域层。观察ModelState.IsValid可以发现,这句代码并不是在定义验证规则,而是调用验证。在控制器上直接调用验证可能并不是什么问题,但初学者可能会认为,既然可以在控制器上调用ModelState.IsValid进行验证,那么其它验证代码也可以放到控制器上。

DDD分层架构之领域实体(验证篇)
        [HttpPost]
public ActionResult 方法名( 实体名 model ) {
if ( ModelState.IsValid == false ) {
//验证失败就返回
}
if ( model.A > 1 ) {
//验证失败就返回
}
if ( model.B > 2 ) {
//验证失败就返回
}
//验证成功就执行后面的代码
}
DDD分层架构之领域实体(验证篇)

  观察上面代码,model.A > 1 已经将本属于领域层的验证定义规则泄露到表现层来了,因为这句代码访问了实体的属性,所谓验证规则,就是对实体属性值进行某些约束。

  既然可以在控制器上写验证,那么就会有人在这里写业务逻辑,所以到了后面,DDD分层架构如同虚设。

  第二,错误的验证时机可能导致验证失败。

  考虑这样的场景,如果实体中某些属性需要调用特定方法来产生结果,当提交到控制器操作时,这些属性还是空值,由于还没有调用特定方法,所以调用ModelState.IsValid可能导致验证失败。

  可以看出,这其实是因为验证的时机不对,验证几乎一定要在某些操作之后来进行,比如初始化操作,当然你可以在调用ModelState.IsValid之前调用特定方法,但这会导致分层不清的问题。

  打个比方,实体中有一个订单号,它是一个字符串类型,并且添加了[Required]特性,需要调用某个方法来创建订单号,当订单实体被提交到控制器操作时,调用ModelState.IsValid就会失败,因为订单号现在是空值。当然你可以把生成订单号的操作提前到创建订单界面之前,这样再提交过来就没问题了,在这个例子上一般是可行的,但有些操作你可能无法提前。

  第三,无法保证验证完整性,可能需要多次验证。

  很多时候,DataAnnotations无法满足我们的需求,所以我们还需要为特定业务需求写一些定制的验证代码。而ModelState.IsValid只能验证DataAnnotations特性,所以这时候验证通过意义不大,因为你需要在后面再验证一次。当然你可以通过一些手段进行扩展,让ModelState.IsValid能够验证你的特定规则,但没有多大必要,因为表现层在分层上的要点就是尽量不要写代码。

  第四,导致冗余代码。

  现在来观察每个ModelState.IsValid判断都干了些什么工作,一般都会转换成客户端的特定消息,比如某种格式的Json,然后返回给客户端显示出来。为了这样一个简单的功能,需要在大量的方法上添加这个判断吗?更好的方法是把这个判断抽象到控制器基类,由基类来进行处理,其它地方有错误抛出异常就可以了。这样可以得到一个统一的异常处理模型,并且消除了大量冗余代码。从这里也可以看出,打造你的应用程序框架,总是从这些不起眼的地方着手,反复考虑每个判断,每行代码是不是可以消灭,把尽量多的东西抽象到框架中,这样在开发过程中更多工作就会自动完成,不断提炼可以让你的工作越来越轻松。

  综上所述,在表现层进行验证并不是一个好方法,执行验证可以在应用层,而定义验证就一定要在领域层。下面开始介绍如何对领域实体进行验证支持。

  现在有一个员工实体,叫Employee,如下所示。

DDD分层架构之领域实体(验证篇)
    /// <summary>
/// 员工
/// </summary>
public class Employee : EntityBase {
/// <summary>
/// 姓名
/// </summary>
[Required( ErrorMessage = "姓名不能为空" )]
public string Name { get; set; } /// <summary>
/// 性别
/// </summary>
[Required( ErrorMessage = "性别不能为空" )]
public string Gender { get; set; } /// <summary>
/// 年龄
/// </summary>
[Range(18,50,ErrorMessage = "年龄范围为18岁到50岁")]
public int Age { get; set; } /// <summary>
/// 职业
/// </summary>
[Required(ErrorMessage = "职业不能为空")]
public string Job { get; set; } /// <summary>
/// 工资
/// </summary>
public double Salary { get; set; }
}
DDD分层架构之领域实体(验证篇)

  为了简单起见,我把一些东西简化了,比如性别用枚举更好,但用了字符串类型,而年龄根据出生年月推断会更好等等。这个例子只是想说明验证的方法,所以不用考虑它的真实性。

  可以看见,在员工实体的属性上添加了一些DataAnnotations特性,这些特性保证了基本的验证。现在定义了验证规则,那么怎么执行验证呢?前面已经说了,用ModelState.IsValid虽然可以实现这个功能,但不是最优方法,所以我们要另谋出路。

  执行验证的最简单方法可能长成这样:employee.Validate(),employee是Employee的实例,Validate是Employee中的一个实例方法。

  注意,现在我们在领域实体中定义了一个方法,这可能会打破你平时的习惯和认识。多年的习惯可能让你对实体的认识就是,只有一堆属性的对象。现在要把思维转变过来,这个转变至关重要,它是你进入面向对象开发的第一步。

  想想看,你现在要进行验证,应该上哪才能找到这个能执行验证的方法呢?如果它不在实体中,那么它可能在表现层,也可能在应用层,还可能在领域服务中,当然还有可能不存在,都还没人实现呢。

  所以我们需要给业务逻辑安家,这样才能帮你统一的管理业务逻辑,并提供唯一的访问点。这个家最好的地方就是实体本身,因为属性全都在这里面,属性上执行的逻辑也全部放进来,就能实现对象级别的高内聚。当属性和逻辑发生变化时,对外的方法接口可能不变,这时候所有变化引起的影响就被限制在实体内部,这样就达到了更低的耦合。

  下面,我们来实现Validate方法。

  首先考虑,这个方法应该被定义在哪呢?是不是每个实体上都定义一个,由于验证对于绝大部分实体都是必须的功能,所以需要定义到层超类型上,即EntityBase。

  再来考虑一下Validate的方法签名。需要一个返回值吗,比如bool值,我在之前的文章已经讨论了返回bool值来指示是否验证通过不是一个好方法,所以我们现在返回void。那么方法参数呢?由于现在是直接在实体上调用,所以参数也不是必须的。

        /// <summary>
/// 验证
/// </summary>
public void Validate() {
}

  为了实现这个方法,我们必须要能够验证实体上的DataAnnotations特性,这在前面的验证公共操作类已经准备好了。我们在Util.Validations命名空间中定义了IValidation接口,并使用企业库实现了这个接口。

  考虑在EntityBase的Validate方法中该如何获得IValidation的实例呢?依赖程度最低的方法是使用构造方法注入。

DDD分层架构之领域实体(验证篇)
    /// <summary>
/// 领域实体
/// </summary>
/// <typeparam name="TKey">标识类型</typeparam>
public abstract class EntityBase<TKey> {
/// <summary>
/// 验证器
/// </summary>
private IValidation _validation; /// <summary>
/// 标识
/// </summary>
[Required]
public TKey Id { get; private set; } /// <summary>
/// 初始化领域实体
/// </summary>
/// <param name="id">标识</param>
/// <param name="validation">验证器</param>
protected EntityBase( TKey id, IValidation validation ) {
Id = id;
_validation = validation;
}
}
DDD分层架构之领域实体(验证篇)

  在外部通过构造方法把需要的验证器实例传进来,这样甚至不需要在Util.Domains中引用任何程序集。这看起来很诱人,但不要盲目的追求低耦合。考虑验证器的稳定性,这应该非常高,你基本不会随便换掉它,更不会动态更换它。再看构造方法,多了一个参数,这会导致实体使用起来非常困难。所以为了不必要的扩展性牺牲易用性,并不划算。

  另一种方法是通过Validate方法的参数注入,这样可能要好些,但还是会让方法在调用时变得难用。

  应用程序框架只是给你或你的团队在小范围使用的,它不像.Net Framework或第三方框架在全球范围使用,所以你没有必要追求非常高的扩展性,如果发生变化导致你需要修改应用程序框架,你打开来改一下也不是啥大问题,因为框架和项目源码都在你的控制范围内,不见得非要达到OCP原则。当然,如果发生变化的可能性高,你还是需要考虑降低依赖。在依赖性和易用性间取舍,一定要根据实际情况,不要盲目追求低耦合。

  另外再考虑每个实体可能需要更换不同的验证器吗?如果需要,那就得引入工厂方法模式。由于这个验证器只是用来验证DataAnnotations特性的,所以没这必要。

  那么直接在EntityBase中new一个Validation实例好不好呢?嘿嘿,这我也只能说要求太低了。一个折中的方案是使用简单静态工厂,如果需要更换验证器实现,你就把这个工厂打开来改改,其它地方不动,一般来讲这已经够用。

  为Util.Domains引用Util.Validations.EntLib程序集,并在Util.Domains中添加ValidationFactory类。

DDD分层架构之领域实体(验证篇)
using Util.Validations;
using Util.Validations.EntLib; namespace Util.Domains {
/// <summary>
/// 验证工厂
/// </summary>
public class ValidationFactory {
/// <summary>
/// 创建验证操作
/// </summary>
public static IValidation Create() {
return new Validation();
}
}
}
DDD分层架构之领域实体(验证篇)

  在EntityBase类中添加Validate方法。

DDD分层架构之领域实体(验证篇)
        /// <summary>
/// 验证
/// </summary>
public void Validate() {
var result = ValidationFactory.Create().Validate( this );
if ( result.IsValid )
return;
throw new Warning( result.First().ErrorMessage );
}
DDD分层架构之领域实体(验证篇)

  我们在Validate方法中将领域实体本身传入Validation实例中进行验证,获得验证结果以后,判断如果验证失败就抛出异常,这里的异常是我们在上一篇定义的异常公共操作类Warning,这样我们就知道是业务上发生了错误,可以把这个抛出的消息显示给客户。

  完成了上面的步骤以后,就可以进行基本的验证了。但是只能用DataAnnotations进行基本验证,很明显无法满足我们的实际需求。

  现在来假想一个验证需求,你的老板是个好人,你们的人力资源系统也是自己开发的,他要求程序员老男人的工资不能小于一万。换句话说,如果是一个程序员老男人,他的信息被保存到数据库的时候,工资不能小于一万,否则就是非法数据。程序员老男人这个词汇很明显不存在,为了加深你的印象,用它来给你演示业务概念如何被映射到系统中。

  程序员老男人包含三个条件:

  1. 职业 == 程序员
  2. 年龄 > 40
  3. 性别 == 男

  你为了验证这个需求,能使用DataAnnotations特性吗,也许你真的可以,但是大部分人都做不到,哪怕做到也异常复杂。

  为了实现这个功能,你可能在调用了Validate()方法之后,紧接着进行判断。

 employee.Validate();
if ( employee.Job == "程序员" && employee.Age > 40 && employee.Gender == "男" && employee.Salary < 10000 )
throw new Warning( "程序员老男人的工资不能低于1万" );

  如果你调用Validate是在应用层,这下好了,把验证逻辑泄露到应用层去了,很快,你的分层架构就会乱成一团。

  时刻记住,只要是业务逻辑,你就一定要放到领域层。验证是业务逻辑的一个重要组成部分,这就是说,没有验证,业务逻辑可能是错的,因为进来的数据不在合法范围。

  现在把这句判断移到Employee实体,最合适的地方就是Validate方法中,但这个方法是在基类EntityBase上定义的,为了能够给基类方法添加行为,可以把EntityBase中的Validate方法设为虚方法,这样子类就可以重写了。

  基类EntityBase中的Validate方法修改如下。

DDD分层架构之领域实体(验证篇)
        /// <summary>
/// 验证
/// </summary>
public virtual void Validate() {
var result = ValidationFactory.Create().Validate( this );
if ( result.IsValid )
return;
throw new Warning( result.First().ErrorMessage );
}
DDD分层架构之领域实体(验证篇)

  在Employee实体中重写Validate方法,注意必须调用base.Validate(),否则对DataAnnotations的验证将丢失。

        public override void Validate() {
base.Validate();
if ( Job == "程序员" && Age > 40 && Gender == "男" && Salary < 10000 )
throw new Warning( "程序员老男人的工资不能低于1万" );
}

  对于应用层来讲,它并不关心具体怎么验证,它只知道调用employee.Validate()就行了。这样就把验证给封装了起来,为应用层提供了一个清晰而简单的API。

  一般说来,DataAnnotations和重写Validate方法添加自定义验证可以满足大部分领域实体的验证需求。但是,如果验证规则很多,而且很复杂,会发现重写的Validate方法很快变成一团乱麻。

  除了代码杂乱无章之外,还有一个问题是,业务概念被淹没在大量的条件判断中,比如Job == "程序员" && Age > 40 && Gender == "男" && Salary < 10000这个条件实际上代表的业务概念是程序员老男人的工资规则。

  另一个问题是,有些验证规则只在某些特定条件下进行,直接固化到实体中并不合适。

  当验证变得逐渐复杂时,就需要考虑将验证从实体中拆分出来。将一条验证规则封装到一个验证规则对象中,这就是规约模式在验证上的应用。规约的概念很简单,它是一个谓词,用来测试一个对象是否满足某些条件。规约的强大之处在于,将一堆相关的条件表达式封装起来,清晰的表达了业务概念。

  把程序员老男人的工资规则提取到一个OldProgrammerSalaryRule类中,如下所示。

DDD分层架构之领域实体(验证篇)
    /// <summary>
/// 程序员老男人的工资验证规则
/// </summary>
public class OldProgrammerSalaryRule {
/// <summary>
/// 初始化程序员老男人的工资验证规则
/// </summary>
/// <param name="employee">员工</param>
public OldProgrammerSalaryRule( Employee employee ) {
_employee = employee;
} /// <summary>
/// 员工
/// </summary>
private readonly Employee _employee; /// <summary>
/// 验证
/// </summary>
public bool Validate() {
if ( _employee.Job == "程序员" && _employee.Age > 40 && _employee.Gender == "男" && _employee.Salary < 10000 )
return false;
return true;
}
}
DDD分层架构之领域实体(验证篇)

  上面的验证规则对象,通过构造方法接收业务实体,然后通过Validate方法进行验证,如果验证失败就返回false。

  返回bool值的一个问题是,错误描述就拿不到了。为了获得错误描述,我把返回类型从bool改成ValidationResult。

DDD分层架构之领域实体(验证篇)
using System.ComponentModel.DataAnnotations; 

namespace Util.Domains.Tests.Samples {
/// <summary>
/// 程序员老男人的工资验证规则
/// </summary>
public class OldProgrammerSalaryRule {
/// <summary>
/// 初始化程序员老男人的工资验证规则
/// </summary>
/// <param name="employee">员工</param>
public OldProgrammerSalaryRule( Employee employee ) {
_employee = employee;
} /// <summary>
/// 员工
/// </summary>
private readonly Employee _employee; /// <summary>
/// 验证
/// </summary>
public ValidationResult Validate() {
if ( _employee.Job == "程序员" && _employee.Age > 40 && _employee.Gender == "男" && _employee.Salary < 10000 )
return new ValidationResult( "程序员老男人的工资不能低于1万" );
return ValidationResult.Success;
}
}
}
DDD分层架构之领域实体(验证篇)

  验证规则对象虽然抽出来了,但是在哪调用它呢?最好的地方就是领域实体的Validate方法,因为这样应用层将非常简单。

  为了能够在领域实体的Validate方法中调用验证规则对象,需要将验证规则添加到该实体中,这可以在Employee中增加一个AddValidationRule方法。

DDD分层架构之领域实体(验证篇)
    /// <summary>
/// 员工
/// </summary>
public class Employee : EntityBase {
//构造方法和属性 /// <summary>
/// 验证规则集合
/// </summary>
private List<OldProgrammerSalaryRule> _rules; /// <summary>
/// 添加验证规则
/// </summary>
/// <param name="rule">验证规则</param>
public void AddValidationRule( OldProgrammerSalaryRule rule ) {
if ( rule == null )
return;
_rules.Add( rule );
} /// <summary>
/// 验证
/// </summary>
public override void Validate() {
base.Validate();
foreach ( var rule in _rules ) {
var result = rule.Validate();
if ( result == ValidationResult.Success )
continue;
throw new Warning( result.ErrorMessage );
}
}
}
DDD分层架构之领域实体(验证篇)

  如果另一个领域实体需要使用验证规则,就要复制代码过去改一下,这显然是不行的,所以需要把添加验证规则抽到基类EntityBase中。为了支持这个功能,首先要为验证规则抽象出一个接口,代码如下。

DDD分层架构之领域实体(验证篇)
using System.ComponentModel.DataAnnotations; 

namespace Util.Validations {
/// <summary>
/// 验证规则
/// </summary>
public interface IValidationRule {
/// <summary>
/// 验证
/// </summary>
ValidationResult Validate();
}
}
DDD分层架构之领域实体(验证篇)

  在EntityBase中添加AddValidationRule方法,并修改Validate方法,代码如下。

DDD分层架构之领域实体(验证篇)
        /// <summary>
/// 验证规则集合
/// </summary>
private readonly List<IValidationRule> _rules; /// <summary>
/// 添加验证规则
/// </summary>
/// <param name="rule">验证规则</param>
public void AddValidationRule( IValidationRule rule ) {
if ( rule == null )
return;
_rules.Add( rule );
} /// <summary>
/// 验证
/// </summary>
public virtual void Validate() {
var result = ValidationFactory.Create().Validate( this );
foreach ( var rule in _rules )
result.Add( rule.Validate() );
if ( result.IsValid )
return;
throw new Warning( result.First().ErrorMessage );
}
DDD分层架构之领域实体(验证篇)

  现在让OldProgrammerSalaryRule实现IValidationRule接口,应用层可以像下面这样调用。

employee.AddValidationRule( new OldProgrammerSalaryRule( employee ) );
employee.Validate();

  可以在几个地方为领域实体设置验证规则对象。

  1. 领域实体的构造方法中。
  2. 具体的领域实体重写Validate方法中。
  3. 当工厂创建领域实体(聚合)时。
  4. 领域服务或应用服务调用领域实体进行验证时。

  设置验证规则的要点是,稳定的验证规则尽量放到实体中,以方便使用。

  现在还有一个问题是,验证处理是抛出一个异常,这个异常的消息设置为验证结果集合的第一个消息。这在大部分时候都够用了,但是某些时候对错误的处理会有所不同,比如你现在要显示全部验证失败的消息,这时候将要修改框架。所以把验证的处理提取出来是个不错的方法。

  定义一个验证处理的接口IValidationHandler,这个验证处理接口有一个Handle的处理方法,接收一个验证结果集合的参数,代码如下。

DDD分层架构之领域实体(验证篇)
    /// <summary>
/// 验证处理器
/// </summary>
public interface IValidationHandler {
/// <summary>
/// 处理验证错误
/// </summary>
/// <param name="results">验证结果集合</param>
void Handle( ValidationResultCollection results );
}
DDD分层架构之领域实体(验证篇)

  由于只需要在特殊情况下更换验证处理实现,所以定义一个默认的实现,代码如下。

DDD分层架构之领域实体(验证篇)
    /// <summary>
/// 默认验证处理器,直接抛出异常
/// </summary>
public class ValidationHandler : IValidationHandler{
/// <summary>
/// 处理验证错误
/// </summary>
/// <param name="results">验证结果集合</param>
public void Handle( ValidationResultCollection results ) {
if ( results.IsValid )
return;
throw new Warning( results.First().ErrorMessage );
}
}
DDD分层架构之领域实体(验证篇)

  为了能够更换验证处理器,需要在EntityBase中提供一个方法SetValidationHandler,代码如下。

DDD分层架构之领域实体(验证篇)
        /// <summary>
/// 验证处理器
/// </summary>
private IValidationHandler _handler; /// <summary>
/// 设置验证处理器
/// </summary>
/// <param name="handler">验证处理器</param>
public void SetValidationHandler( IValidationHandler handler ) {
if ( handler == null )
return;
_handler = handler;
}
DDD分层架构之领域实体(验证篇)

  在EntityBase构造方法中初始化_handler = new ValidationHandler(),并修改Validate方法。

DDD分层架构之领域实体(验证篇)
        /// <summary>
/// 验证
/// </summary>
public virtual void Validate() {
var result = ValidationFactory.Create().Validate( this );
foreach ( var rule in _rules )
result.Add( rule.Validate() );
if ( result.IsValid )
return;
_handler.Handle( result );
}
DDD分层架构之领域实体(验证篇)

  最后,用提取方法重构来改善一下Validate代码。

DDD分层架构之领域实体(验证篇)
        /// <summary>
/// 验证
/// </summary>
public virtual void Validate() {
var result = GetValidationResult();
if ( result.IsValid )
return;
HandleValidationResult( result );
} /// <summary>
/// 获取验证结果
/// </summary>
private ValidationResultCollection GetValidationResult() {
var result = ValidationFactory.Create().Validate( this );
Validate( result );
foreach ( var rule in _rules )
result.Add( rule.Validate() );
return result;
} /// <summary>
/// 验证并添加到验证结果集合
/// </summary>
/// <param name="results">验证结果集合</param>
protected virtual void Validate( ValidationResultCollection results ) {
} /// <summary>
/// 处理验证结果
/// </summary>
private void HandleValidationResult( ValidationResultCollection results ) {
_handler.Handle( results );
}
DDD分层架构之领域实体(验证篇)

  注意,这里添加了一个Validate( ValidationResultCollection results )虚方法,这是一个钩子方法,提供它的目的是允许子类向ValidationResultCollection中添加自定义验证的结果。它和重写Validate()方法的区别是,如果重写Validate()方法,那么你将需要自己处理验证,而Validate( ValidationResultCollection results )方法将以统一的方式被handler处理。

  这样,我们就实现了验证规则定义与验证处理的分离。

  最后,再对这个小例子完善一下,可以将“程序员老男人”这个概念封装到Employee的一个方法中。

        /// <summary>
/// 是否程序员老男人
/// </summary>
public bool IsOldProgrammer() {
return Job == "程序员" && Age > 40 && Gender == "男";
}

  OldProgrammerSalaryRule验证规则的实现修改为如下代码。

DDD分层架构之领域实体(验证篇)
        /// <summary>
/// 验证
/// </summary>
public ValidationResult Validate() {
if ( _employee.IsOldProgrammer() && _employee.Salary < 10000 )
return new ValidationResult( "程序员老男人的工资不能低于1万" );
return ValidationResult.Success;
}
DDD分层架构之领域实体(验证篇)

  这样不仅概念上更清晰,而且当多个地方需要对“程序员老男人”进行验证时,还能体现出更强的封装性。

  由于代码较多,完整代码就不粘贴了,如有需要请自行下载。

  如果你有更好的验证方法,请一定要告诉我,等我理解以后分享给大家。

  .Net应用程序框架交流QQ群: 386092459,欢迎有兴趣的朋友加入讨论。

  谢谢大家的持续关注,我的博客地址:http://www.cnblogs.com/xiadao521/

  下载地址:http://files.cnblogs.com/xiadao521/Util.2014.11.20.1.rar

版权所有,转载请注明出处 何镇汐的技术博客
 
上一篇:(IOS)截图Demo


下一篇:对jsp的初步了解及生成war包(一)