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

对，我说的单体就是singleton。

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

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

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

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

我的分层里有service的。

交给spring管理没问题

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

我持保留看法~

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

不重复。

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

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

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

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

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

千万不要在一个应用建两个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形式。

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

这里错了

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

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

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

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

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

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