依赖注入DI很大程度的帮助测试单元化。这对层与层之间的依赖关系,几乎是真理。
如对数据读写的依赖关系,用IRepository替换之后,所有用到IRepository的类,如Serivce这一层的ExamService,在测试时,只需要传入一个Mock的IRepository类,就不需要使用真实的数据库对它测试了.
我们的另外一层Controller也用到Service这一层,同样我为Service这一层的实现也提出一个接口IExamService,在Controller的构造器中传入IExamService的Mock类。因此,很容易的让测试关注于Controller本身的行为和功能。甚至可以在ExamService类实现之前,我们就可以测试和实现Controller类。这是依赖注入的优势。
这一整套分层，解耦和测试我们已经实现了,并形成一个规范的过程和成形的框架。现在已经简单到按部就班,就能轻松完成,甚至后期都可以考虑自动生成这部分代码。但这部分现在不是本文的重点。
业务域的简单案例---构造器赋值
当我们的注意力转移到业务域时，情景有了悄悄的改变。业务域中,类与类之间有更多更复杂的依赖关系。相比之下，三层之间反而简单。
这里,把我正在做的考试（Exam）类做一个简单的背景介绍。考试，对于身经百战的我们应该不陌生了，让我们好好分析,看看熟悉身影的陌生之面。另外,我这里考试更多是拿社会化考试作分析目标。
一个考试有三个很重要的要素:考试代码（考试定义）;考区（北京考区,湖南考区）；考试日期。这三个要素,唯一标识一个考试,也就是说,同一个考区,同一个考试定义在同日期,我就认为是同一个考试。很简单的逻辑,为了体现这个逻辑,我把这三个要素,放在考试类的构造器中。为什么?任何一个要素的缺失,考试对象的存在都没有任何含义，所以一开始构造的时候，就要传入。从另一个角度,考区+考试定义+日期是考试的业务ID,是唯一标识，必须贯穿于业务对象的始终。
看代码:
public class Exam { public Exam(District district, ExamDef exam_def, Date date) { District = district; ExamDef = exam_def; Date = date; } } |
通过构造器,从外部传入三个对象后,把它们赋给考试的三不属性,而这三个属性是只读, Private是为了给nHibernate和构造器使用的。为什么?如前所说他们是业务动,在创建之后,再修改没有任何含义。
看代码:
public class Exam { public Exam(District district, ExamDef exam_def, Date date) { District = district; ExamDef = exam_def; Date = date; } public virtual ExamDef ExamDef { get; private set; } public virtual District District { get; private set; } public virtual Date Date { get;private set; } } |
