第88页

访问仓库的各种选择
仓库主要由领域服务使用，不过它们也被一些实体如PendingOrder调用。要对仓库对象调用方法，调用者必须明显持有该对象的引用。此前你已看到仓库如何作为构造函数参数传入PlaceOrderSerivce。然而，就下面我要描述的理由来看，对领域模型实体，并不总能做到这一点。下面，我们来探究一下这个问题及其各种解决方法。
最便利的方案是将仓库作为构造函数参数传入实体，和它们传入服务的方式一样。这样以来，实体就能借助轻量级容器的构造子注入机制进行初始化。与将仓库作为方法参数传递相比，将仓库作为构造函数参数传递要简单得多，而且不存在使用singleton时的缺点，我稍后再作描述。然而，使用这种方案初始化实体并不那么直接，因为它与服务不同，服务一般由轻量级容器实例化，而实体则是在数据库加载时，由持久层框架创建的。
默认情况下，持久层框架使用类的默认构造函数直接创建对象，因此不可能传入任意必须的对象。有些（并非所有）持久层框架具备可配置的对象实例化机制，允许应用程序控制对象如何实例化。应用程序可以配置持久层框架，请参看http://hibernate.org/182.html[Hibernate注入]。不过，由于该方案不是到处都有，因此我们不打算在本书中使用这种方案。
另一种选择是使用静态方法和变量实现仓库。例如，你可以singleton或ThreadLocal实现仓库。这种方案对所有持久层框架都有效，而且不要求仓库到处传递，有时，代码可能因此过于复杂。静态方法和变量存在的问题是它们使代码更难测试。例如，它们会阻止你使用替代实现比如模拟对象，因为你无法把静态方法或变量的访问重定向至另一个类。由于代码依赖必须初始化的静态变量，因此它们还引入了隐藏的依赖。总之，最好避免静态方法和变量。
由于只有某些持久层框架允许你使用构造子注入初始化实体，而使用静态方法和变量又存在一些严重的缺点，因此通常将仓库作为方法参数传递比较有意义。它避开了使用singleton存在的问题，而且不依赖持久层框架的专有特性。然而，采用这种方案也存在一个缺点，它可能在代码中引起连锁反应。我们可能得修改许多方法，使之以仓库作为参数之一，以便将它们从服务（服务通过构造子注入获取它们）传递至用到这些仓库的方法中。