矛盾：充血的领域模型和Web服务器装载的spring context

情况是这样的：

1 一个架构为struts2,spring,hibernate的web应用。
2 采用充血的领域模型，即领域bean里含有一些简单的业务逻辑，例如CRUD之类的操作。这些操作需要hibernate的session factory以便访问数据库。
3 Spring中定义了session factory，因此可以将它注入任何需要的地方。同样也可以注入领域bean和service类中。

但问题是领域bean因为比较小（其实也不小，如果充血的话），一般用new的方式生成，因此无法从Spring中获得session factory。像service类比较大，一般是从Spring中获得实例，因此注入了session factory，没有问题。

如果是失血模型的话，领域类里只有getter 和setter方法，因此不存在注入session factory的问题。

当然我也可以用BeanFactory.getBean("beanName")的方式获得session factory，但这样就不够好看了，出现了applicationContext和BeanFactory并存的局面，感觉不优雅( 我现在的Spring是通过web.xml在Web服务器启动时载入的，因此是application context）。

难道大家不用充血模型？

在Spring reference的3.9. Glue code and the evil singleton中，似乎有些提示，但不怎么明白。

评论

20 楼 nfxu 2009-01-06  

czx566 写道

的确我觉得我表达的能力还有所欠缺~
我准备写4，再补充论证这个问题。

我主题的意思是：
   任何一个软件系统，其实都应该包含了 过程和对象 两个部分。
   一般来说我们应该用service层代码实现过程逻辑，而领域对象则实现对象部分。
   那么对象的管理，一般来说我认为交给IOC去管理，是非常合适的。
   为什么？
   对于对象的调用者来说（即过程代码），对象怎么组成的，这个对象背后是否
   依赖其它对象或则环境，是不应该去关注和关心的，所以我们事例化一个对象
   都应该通过一个工厂去取得，而对象背后之间的关系，我们应该完全交给IOC
   来建立。这个和我过程代码无关。

    当然我们也可以将service层的代码 也归纳为一个对象，那我当然也可以将这
   个对象交给IOC去管理，这样就是IOC无边界的一种应用。那么会出现什么情况
   了？
    第一 我在编排IoC的配置文件时（即spring的xml文件），那么此配置文件是
   和你的过程逻辑有较强的耦合度的。就如同我例举的，我编写的明明是商场的配
   置，但我却要关心，这个主板商家在那里等等，如果有一天还出一个卖冰棍的，那
   不更莫名了?
    第二 不够OO;   
    当然，上面的理由总的说起来也无关大局~除非你有完美主义的倾向，呵呵
   
   所以我认为在service层 以上，过程逻辑 更普遍的时候，不应该用IOC.
   而只有到了领域模型以下，这个完全符合OO的层次，IOC才用得有意义.
  

我明白了你的意思。

对于service中的过程化的业务逻辑来说，他们需要操纵领域Bean，这时领域Bean对业务逻辑来说，属于召之即来，呼之即去的非长期依赖的对象，而IOC无论是setter方法还是构造器方法注入的都是类的成员变量类型的领域Bean，同service类具有相同的生民周期，自然显得多余了。所以，在service类中使用工厂模式或new的方法 在过程中 创建领域Bean更为合适。

而对于领域Bean中的DAO来说，只要领域Bean一出现，他就依赖于DAO，领域Bean死了DAO还不会死，因为DAO属于基础设施（所以用单例的方式存在），因此用IOC注入的方式比较合适。

这是我的理解。呵呵。我觉得我目前也是这么做的。只不过我没有用工厂方式在service里创建领域Bean，而是用new。

19 楼 lgx522 2009-01-06  

这个所谓“贫血”、“充血”之论，大家其实没必要当真，扯来扯去，搞成经院式的空洞辩论了。
世间事本无“一招仙”的解决方法，如此在意“招式”是很无聊的。

国内搞Java和Spring的，大凡有点熟的，好像总喜欢扯点这类问题，好像挺有“深度”，其实是浪费时间精力。就算大家把MF的“模式”都搞清楚了，就真能解决一切问题了吗？不如学一学.NET、PHP和RoR，低头做点实事。Java世界不是用来折腾说事的，有能耐的，多写点有用的jar做开源才是要紧。

18 楼 czx566 2009-01-05  

的确我觉得我表达的能力还有所欠缺~
我准备写4，再补充论证这个问题。

我主题的意思是：
   任何一个软件系统，其实都应该包含了 过程和对象 两个部分。
   一般来说我们应该用service层代码实现过程逻辑，而领域对象则实现对象部分。
   那么对象的管理，一般来说我认为交给IOC去管理，是非常合适的。
   为什么？
   对于对象的调用者来说（即过程代码），对象怎么组成的，这个对象背后是否
   依赖其它对象或则环境，是不应该去关注和关心的，所以我们事例化一个对象
   都应该通过一个工厂去取得，而对象背后之间的关系，我们应该完全交给IOC
   来建立。这个和我过程代码无关。

    当然我们也可以将service层的代码 也归纳为一个对象，那我当然也可以将这
   个对象交给IOC去管理，这样就是IOC无边界的一种应用。那么会出现什么情况
   了？
    第一 我在编排IoC的配置文件时（即spring的xml文件），那么此配置文件是
   和你的过程逻辑有较强的耦合度的。就如同我例举的，我编写的明明是商场的配
   置，但我却要关心，这个主板商家在那里等等，如果有一天还出一个卖冰棍的，那
   不更莫名了?
    第二 不够OO;   
    当然，上面的理由总的说起来也无关大局~除非你有完美主义的倾向，呵呵
   
   所以我认为在service层 以上，过程逻辑 更普遍的时候，不应该用IOC.
   而只有到了领域模型以下，这个完全符合OO的层次，IOC才用得有意义.
  

17 楼 samm 2009-01-05  

创建新领域bean，这个无从谈起，一个单例Bean不救OK了吗？

这里错了

无法在创建新领域bean的时候用代码显示的获得对DAO引用，用一个非单例bean

16 楼 samm 2009-01-05  

nfxu 写道

嗯。我说的往领域bean里注入session factory实际上是DAO，呵呵。

但是DAO同session factory一样，也是在application context里声明的，对他的引用只能是声明式的注入，无法在创建新领域bean的时候用代码显示的获得对DAO引用，这正是我面临的问题。

也可以这么说，如何在通过Web容器启动了application context后，在代码里取得对这个application context的引用？就像这样：
DomainBean myBean = applicationContext.getBean("domainBean");

千万不要在一个应用建两个context啊，是可以拿的，其实不过是application context是存在application里面的。

方式1
-----------spring 文档------------------

3.5.2.1.  BeanFactoryAware
对于实现了org.springframework.beans.factory.BeanFactoryAware接口的类，当它被BeanFactory创建后，它会拥有一个指向创建它的BeanFactory的引用。

----------^_^强大的分割线^_^--------------

方式2，但好很强大。
WebApplicationContext  wac = WebApplicationContextUtils.getWebApplicationContext(
servletConfig.getServletContext());

很简单，传个参数就可以了。如果觉得传参很麻烦，写个filter或servlet初始一个Util类就OK了(在spring初始化之后)

创建新领域bean，这个无从谈起，一个单例Bean不救OK了吗？

不过充血模型是不依赖持久层框架的，你所说的更象ALL-IN-ONE形式。

15 楼 nfxu 2009-01-05  

czx566 写道

交给spring管理没问题

但用IoC一杆子捅到底，这样做好么？

我持保留看法~

我看了你写的胡说系列，很好，对service和领域Bean的理解我很赞同。我准备收藏下来，回头再读读。

IOC和工厂模式之间的差别，dongwenhua已经表达了这个意思了，所以我就不多说了。我只是想起来一句话，关于IOC的，很有意思，对于对象及其依赖对象之间的关系，就像好莱坞电影里的对话一样，don't call me, i will call you.这是被依赖对象对依赖对象说的。呵呵。

如果考虑到领域Bean的生命周期实际上是由业务逻辑来控制的，那么，由Spring将领域Bean注入业务逻辑所在的service好不好呢？我觉得你的意思是说不好（电脑商城和主板，芯片商户的例子），可是你怎么又说IOC最好实现在领域模型里呢？这个我不是很明白。

14 楼 nfxu 2009-01-05  

不重复。

我的service里主要是处理领域Bean里不能处理的业务逻辑，就是比较大的，超过单个领域Bean范围的逻辑。比如列出一个list，就用service。所以service中也需要DAO。但service和DAO都是单例，所以很容易用Spring来管理。

多说一句，我在action和service之间实际上还有一层，专门用来读取action中传进来的request中的用户数据，组装好后，才交给service层。service层的调用完全采用的是JSE的类，没有和容器相关的类，如HTTP request等。这么做的结果是，我的service层及以下可以直接复用在一个用swing做界面的桌面系统里。

13 楼 nfxu 2009-01-05  

等我先看完你的胡说在说 呵呵

12 楼 czx566 2009-01-05  

交给spring管理没问题

但用IoC一杆子捅到底，这样做好么？

我持保留看法~

11 楼 nfxu 2009-01-05  

其实Spring管理的对象的生命周期的问题，我发帖子之前，一直没有意识到，只是在讨论中才明白过来。

把action交给Spring管理的原因是因为大家都在这么用，而我目前还是处于学习阶段，自然是有样学样啊。你看Spring的文档里，struts的文档里，都在说如何将struts和Spring集成起来，也就是将action交给Spring来管理。

我的分层里有service的。

10 楼 nfxu 2009-01-05  

spyker 写道

你说的单体是单例么？
spring中不是有多例的实现么？
不知道我理解的是不是这样

如果我理解正确的话 那你的那些问题不解决了么

对，我说的单体就是singleton。

对，Spring 中用prototype就可以得到多例。但对于我的领域对象（Bean），我不想交给Spring来管理，也就是说，我想用new的方式自己来管理，因为他们是有生命周期的，在service的逻辑处理完成后，需要被抛弃的。但Spring管理的对象都是单例（有一个例外，就是struts的action），生命周期同整个应用的生命周期一致。

为什么把action也交给Spring来管理呢？很简单，就是因为牛人们都这么做，我要是不这么做的话，岂不是太没品味啦？！

9 楼 nfxu 2009-01-05  

spyker 写道

我觉得你充血模型这块设置的有问题
从测试角度来说
这一块处理的一些业务应该不涉及到持久层这一块的

我觉得这一块应该是简单的一些逻辑处理
不引入其他层的对象

可以做单体测试的

嗯，我不会做单体测试，呵呵  

所以也不怎么往这方面想。但我的主要原则是：处理相同对象的逻辑要集中，关系相近，处理方式相近的逻辑要集中。尽量复用代码，尽量封装代码。在这种原则下，我觉得往领域Bean里放CRUD的数据库操作是我目前能想到的比较好的封装的方法，要不CRUD处理往哪里放？

8 楼 czx566 2009-01-05  

我想我和你一样思考过这个问题

如果愿意，你可以看看我博客的第3篇文章。


IOC有设计边界的~

7 楼 nfxu 2009-01-05  

czx566 写道

我这么理解的你问题

你目前在三层都用到了依赖注入，按照以往的惯例是：
    你的访问发起调用，action 对象由 容器生成，同时在action中应该
同时注入你action依赖的各个领域对象。

但你不想这么实现，你想action的对象依然由容器生成，但action和领域模型之间的关系由factory生成 或则new 生成？

我觉得这不是我能选择的，我没有别的选择。

目前action的对象是由Spring的application context生成的，这个application context是通过Web服务器里的web.xml在服务器启动时装载进入系统的。也就是说，struts2和Spring集成在了一起。

其他的层，例如service，也是通过application context注入到action里的。因为action由application context来管理，所以没有问题。

但现在领域Bean不好由application context来管理，因为不像service一样可以是单体，相反，要由service里的业务逻辑来灵活管理领域Bean的生命周期，也就是说，我觉得在业务逻辑里new各种领域Bean更为自然。

同时，我愿意在领域Bean里加入对数据库的访问以实现CRUD等操作，所以需要在领域Bean里注入DAO。

但现在领域Bean不归application context管理，如何注入由application context管理的DAO？DAO就像service、session factory一样，是单体，可以被application context管理。

6 楼 nighthawk 2009-01-05  

nfxu 写道

嗯。我说的往领域bean里注入session factory实际上是DAO，呵呵。

但是DAO同session factory一样，也是在application context里声明的，对他的引用只能是声明式的注入，无法在创建新领域bean的时候用代码显示的获得对DAO引用，这正是我面临的问题。

也可以这么说，如何在通过Web容器启动了application context后，在代码里取得对这个application context的引用？就像这样：
  DomainBean myBean = applicationContext.getBean("domainBean");

你要真是这么显式的引用，那你干脆new吧，spring也不需要了。没有意义

5 楼 czx566 2009-01-05  

的确，加了，测试要较复杂一些~

但更加oo

呵呵

凡事都有得有失~

4 楼 czx566 2009-01-05  

有持久化就不能做单体测试了么？


我不这么认为

3 楼 czx566 2009-01-05  

我这么理解的你问题

你目前在三层都用到了依赖注入，按照以往的惯例是：
    你的访问发起调用，action 对象由 容器生成，同时在action中应该
同时注入你action依赖的各个领域对象。

但你不想这么实现，你想action的对象依然由容器生成，但action和领域模型之间的关系由factory生成 或则new 生成？

2 楼 nfxu 2009-01-05  

嗯。我说的往领域bean里注入session factory实际上是DAO，呵呵。

但是DAO同session factory一样，也是在application context里声明的，对他的引用只能是声明式的注入，无法在创建新领域bean的时候用代码显示的获得对DAO引用，这正是我面临的问题。

也可以这么说，如何在通过Web容器启动了application context后，在代码里取得对这个application context的引用？就像这样：
  DomainBean myBean = applicationContext.getBean("domainBean");

1 楼 nighthawk 2009-01-05  

new了以后，你往领域bean里set一下DAO，或者直接new的时候构造，不就搞定了？
不过我对领域bean里注入session factory还是持否定的看法。
充血不是就说要用session factory去访问数据库