三层架构之解耦和单元测试

　　依赖注入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; }
}