[译]关于在领域对象中使用依赖注入或服务定位

写在前面

这是我第一次写博客, 还不太会写:(, 不过不怕, 一回生, 两回熟, 慢慢就好了 :-)

下面的这篇译文是我在看完uiafzhdl写的"从贫血领域模型到丰富领域模型"(http://uiafzhdl.iteye.com/blog/40022)系列文章后, uiafzhdl又推荐的一篇博客(http://igorstoyanov.blogspot.com/2005/12/dependency-injection-or-service.html), 就那这个作为我的开篇了^_^, 译文采用英汉对照的形式, 如有不妥, 请大家不吝指正. 谢谢!

Dependency Injection OR Service Locator in Domain Objects
with Spring and Hibernate frameworks <o:p></o:p>

<o:p> </o:p>

The Problem<o:p></o:p>

问题描述<o:p></o:p>

<o:p> </o:p>

Currently, many java applications use Spring framework together with Hibernate. One of the advantages
当下，许多的Java应用都在将Hibernate与Spring框架一起使用。其中的一个优点就是<o:p></o:p>

of that is that we can implement our domain and service objects as POJOs. Most of us are already
我们可以用POJO的方式去实现我们的领域（domain）对象和服务（service）对象。我们中的许多人<o:p></o:p>

convinced of all the benefits that such a type of architecture can have. In architecture like that, domain
已经深信，如此的架构所带来的所有益处。在像这样的架构中，领域对象<o:p></o:p>

objects are managed by Hibernate and service objects are managed by Spring. Also, another advantage
是由Hibernate来管理，而服务对象则是由Spring来管理。同样地，另一个着意使用Spring的优点是<o:p></o:p>

of using Spring specifically is Dependency Injections (DI) of services and resources.<o:p></o:p>

服务和资源（resource）的依赖注入（Dependency Injection，DI）。<o:p></o:p>

The problem is how to retrieve/find/locate services or resources in domain objects since they are
而现在的问题是如何返回/找到/定位在领域对象中的服务或者资源，因为这些领域对象是由<o:p></o:p>

managed by Hibernate and not created through the bean factory of Spring framework?
Hibernate来管理的，而不是通过Spring框架的Bean Factory创建的。<o:p></o:p>

<o:p> </o:p>

Note: we should differentiate between domain, infrastructure and application services (Domain Driven
说明：我们应该区分领域（domain），基础构件（infrastructure）和应用服务（application service）[<o:p></o:p>

Design book - http://domaindrivendesign.org/book). Using infrastructure or application services in
领域驱动设计 －  http://domaindrivendesign.org/book]。在领域对象中使用基础构件或者应用服务<o:p></o:p>

domain objects is rather not appropriate. The problem I am most concerned with here is in the case when
是有些不太合适。不过现在我最关心的问题是在什么情况下<o:p></o:p>

we need to invoke domain services inside of domain objects.
我们需要调用领域对象中领域服务。<o:p></o:p>

<o:p> </o:p>

Can we avoid the problem?
我们能避免这样的问题吗？<o:p></o:p>

<o:p> </o:p>

Probably! The only way to avoid this problem is not to deal with any services/resources in domain objects.
也许吧！惟一能避免这样问题的方式是不去处理领域对象中的任何服务或资源。<o:p></o:p>

We can do this if we coordinate all domain-service cooperation from a service layer. In this case, we don’t
我们能这样做，如果我们来协调位于服务层的领域服务的动作(*)。在这种情况下，我们就不需要<o:p></o:p>

need to bother with dependency injections, service locators, etc. This makes a lot of sense when we
为依赖注入，服务定位以及其他的费心了。这非常有意义，当我们<o:p></o:p>

invoke services in an asynchronous fashion and especially in SOA /EAI types of architectures.
在异步方式种调用服务时，尤其是在SOA/EAI这种类型的架构中。<o:p></o:p>

<o:p> </o:p>

However, there are some disadvantages:
可是呢，这也有一些不足的地方：<o:p></o:p>

- We deprive ourselves from some of the benefits and power of OOP/OOD.
- 我们丧失了OOP/OOD所带来的一些益处和强大的功能.<o:p></o:p>

- Sometimes, service behavior fits very nicely into the domain model when we have a rich domain model
- 有时，服务的行为非常地适合丰富领域模型<o:p></o:p>

rather than an anemic one http://www.martinfowler.com/bliki/AnemicDomainModel.html and http://wrschneider.blogspot.com/2005/01/avoiding-anemic-domain-models-with.html
而不是贫血领域模型[关于贫血模型，参看http://www.martinfowler.com/bliki/AnemicDomainModel.html和http://wrschneider.blogspot.com/2005/01/avoiding-anemic-domain-models-with.html]

<o:p> </o:p>

Why do we get to the problem?
我们为什么会有这样的问题呢？<o:p></o:p>

<o:p> </o:p>

When I start a project I always try to have very well separated service layer from domain objects (usually
当我开始一个项目的时候，我总试图建立一个与领域对象完全分开的服务层（通常，<o:p></o:p>

enforced with different compilation modules for domain objects and service layer). However, in practice
将领域对象和服务层分为不同的编译模块）。但是在实践中<o:p></o:p>

(at least until now) it always turns out that at some point I will need to use some kind of service or
（至少是目前），可是这样的情况总是出现，有时我们需要在领域对象中使用某些<o:p></o:p>

resource in my domain objects (the simplest example is Time Service. A Time Service is usually needed to
服务或者资源（最简单的一个例子就是时间服务。时间服务通常在这种情况下使用：<o:p></o:p>

give synchronized time when the application is deployed / clustered to more than one server. Also, if you
当应用被部署到集群环境时，提供同步的时间。同样的，如果你<o:p></o:p>

need to play with the current time in your tests, this is a perfect solution. Usually when you deal with some
在你的测试中需要使用到时间，这是个很好的解决方案。通常，当你开发某些支付系统时，<o:p></o:p>

kind of payment/billing systems, you will definitely need something like the above). There can be
你会很明确地需要类似上述的服务）。实际开发中会有<o:p></o:p>

numerous examples of domain objects using some kind of service. Usually, most of the applications that
大量的这样的例子,就是使用某种服务的领域对象。通常，多数的有复杂领域模型的<o:p></o:p>

have more complex domains use some kind of services or resources in domain objects.
应用都在领域对象中用着某种服务或资源。<o:p></o:p>

<o:p> </o:p>

Common solution to the problem
这个问题的常用解决办法<o:p></o:p>

In the past when faced with this sort of situations we have usually used some form of Service Locator
在过去每当遇到这样的情形，我们就会在领域对象内使用某种形式的服务定位（Service Locator）<o:p></o:p>

within domain objects in order to retrieve/locate services or resources.
来获取/定位这些服务或资源。<o:p></o:p>

<o:p> </o:p>

However, these days we routinely use Dependency Injection with some form of Inversion of Control
可是呢，在目前的情况下，我们总是习惯性地在某个轻量级的支持反转控制（Inversion of Control, IoC）<o:p></o:p>

lightweight container (Spring for example) to wire up practically everything else in an app - and we would<o:p></o:p>

的容器[如Spring]中使用依赖注入（Dependency Injection, DI）来把实际应用中的一切组织在一起。我们<o:p></o:p>

like to use a consistent approach if at all possible. Unfortunately, our domain objects are constructed by
都希望在任何可能的情况下，使用一种通用的方式来做这件事情。但非常不幸的是，我们的领域对象是由<o:p></o:p>

Hibernate and not Spring.
Hibernate，而不是Spring创建的。<o:p></o:p>

<o:p> </o:p>

The most common solution (and the only one that I have seen in practice for now) is to use Spring
最通用的解决方案（也是我到现在为止，唯一在实践中看到的）是使用Spring框架的DI， <o:p></o:p>

framework DI to inject services into the service layer and to wire up practically everything else in your app
把各种服务注入到服务层中；也把实际应用中的除领域对象外的一切组织在一起。<o:p></o:p>

beside domain objects. The domain objects, on the other side use Spring-based service locators to find
另一个方面，领域对象使用基于Spring的服务定位来找寻<o:p></o:p>

further services/collaborators they need to do their job.
其他在工作中需要的服务/合作者。<o:p></o:p>

This could be workable approach since both the DI and service location mechanisms use the same
这可能是有效的方法，因为无论是依赖注入还是服务定位机制都使用相同的<o:p></o:p>

underlying infrastructure (Spring bean factory), so they can share the same configuration files etc. Also,
底层框架（Spring bean factory），所以他们能共有相同的配置文件等。同样的，<o:p></o:p>

this common solution to the problem has been kind of described in the javadocs for Spring’s
这个问题的一般解决方案是类似于Spring的javadoc中的关于<o:p></o:p>

BeanFactoryBootstrap class with the statement “one singleton to rule them all”. In other words, allow
BeanFactoryBootsrap类的这样的描述：“one singleton to rule them all”。换句话说就是，允许以<o:p></o:p>

singleton access to the bean factory or application context that holds all of the service layer objects.
单实例的形式访问Bean Factory或者拥有所有的服务层对象应用的上下文<o:p></o:p>

<o:p> </o:p>

However, as I stated above, I would like to use a consistent approach if at all possible for retrieving
但是，正如我上面说的，我更愿意用一种一致的方式，如果能最大可能得取得所有的<o:p></o:p>

services. Not to mention all problems that comes with using Service Locator pattern. I guess using Service
服务。在这里不去提及在使用服务定位模式所带来的问题，我猜，将服务定位和依赖注入一起使用要比<o:p></o:p>

Locator with DI injections is a little better than the old style Service Locator but at the end, this is still a
原有的方式好一些。但说到最后，这仍是个单实例的形式。<o:p></o:p>

singleton. At least there is only ONE singleton in the entire app instead of one for each service object.
至少这样，在整个应用中只有唯一一个单实例，而不是每个服务对象一个。<o:p></o:p>

<!---->
(未完)<!---->