依赖注入
  
    接口分离，就像上面所讨论的，导致了一个难题：当领域层仅仅知道接口时，怎样才能给予具体的DAO 执行情况。依赖注入 ，也就是我们所知道控制翻转(IoC)，可以应用这个技术解决刚才的问题。有依赖注入 ，就可能删除具体对象的许多直接实例化，以及不灵活性（在直接调用新的关键词时，导致了不灵活性）。依赖注入可以通过手工或IoC容器来执行。人工的方法是简单地把对象所“依赖的服务”放入他的所在构造器或者属性中。我曾经在CodeProject写个一篇名为《Dependency Injection for Loose Coupling.》介绍这个方法。（“依赖的服务”可能是个DAO，是个邮件系统、或者任何其他外在支持、花费巨大的任何系统，或者一定不能在单元测试中被使用的资源）人工方法对于单元测试非常有用，因为在描述功能方面，清晰地使具体依赖关系的引用通过（单元测试）是很有帮助的。（Martin Fowler在详细的价值方面有很好的见解。），可能通过由代码或者XML 驱动的IoC Container 来操作依赖注入 。Fowler还写了关于IoC Containers和service locators的介绍，在两者之间做了一个正确的选择。想象下把IoC容器作为解耦的灵丹妙药. 一个IoC容器的优点包括一个包含灵活、松耦合框架和强调以接口开发。缺点是实施中增加了复杂性。在开发一个程序过程中，这是从多需要考虑灵活性和复杂性如何取舍的其中一个。这里有两个非常好的IoC容器工具以供使用：

   • Castle Windsor：通过使用XML 配置和强烈输入的declarations的混合体 ，Castle Windsor, IoC Container 提供了很多IoC支持。与其他选择相比较时，Castle Windsor带给表格的一些好处是更少的XML以及更多的compile-time error catching 。Castle Project还有一些其它强有力的模式，如果你寻找的不仅仅是IoC时，Castle Project使得它成为一个非常有吸引力的选择。这个IoC Container中有广泛的支持，在.NET发展团体里，IoC Container产生了许多争论。"Enterprise" NHibernate Sample包括使用Castle Windsor的例子。

    • Spring .NET:这个构造提供了IoC，这个IoC是通过XML配置文件定义的。像Castle Project一样，Spring.NET也提供了大量种类的额外发展工具。对来自于Java世界的开发者来说，这个选择特别诱人，而且这个选择早已与Spring Framework很熟悉。

    我发现：在测试单元外，使用一个IoC Container非常有帮助，使Aspx页面中单元测试获得依赖，也可以避免直接调用新的关键词。而且这将进一步在一个表示层或者服务层里连接依赖项 。

契约式设计

    Design-by-Contract (DBC)很简单，而且是不需要再一次使用调试器的最好办法。尽管没有经常讨论这种技术，但是这种技术应该得到和测试驱动开发所得到的同样的赞扬。（我并不是说DBC嫉妒，但是它应该得到那些表扬。）它提高了质量，减少了空检查，而且减少了调试时间，极大地提高了应用程序的总体稳定性。描写得更详细一点，DBC 是一种技术，在契约上对你的代码的用户负责（通常是你，或者你自己）以一种特殊的方式来使用方法和属性。因为这些方法和属性允诺它们将成功地完成给予的任务要求。如果没有遵循合同，就会导致异常。首先可能很严重，但是要经过很长时间才能提高代码质量。有DBC时，当调用方法或者属性的时候，前提条件就会调用契约任务必须遵循的东西。后条件调用契约任务被保证的东西。我非常推荐阅读introduction to Design-by-Contract这篇文章，快速使用它时，可以将你迅速地连接起来。这篇文章包括的例子项目使用一个被修改的DBC，而此DBC最初是Kevin McFarlane写的。当这篇文章的例子包含的变化维护合同任务，且无视编译模式时，原型允许有条件的编译，以此来为调用模式打开合同，或者为释放模式关闭合同。依我看来，一个合同总是一个合同，而且行为永远都不会改变。

    在这个代码中，你将发现Check.Require中定义了前条件，然而Check.Ensure定义了后置条件。因为DBC 不是domain-specific，这个类型被很正确地拔到了一个可再度使用的工具库，此工具库在"enterprise"例子里。