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