J2EE application without Spring

请看TSS上的讨论Developing J2EE application without Spring（奉劝做好心理觉悟，嘿）：
http://www.theserverside.com/news/thread.tss?thread_id=38021

spring是一个IoC容器，运用的好的人，写的代码一点都不依赖Spring，完全不需要import Spring的API；用不好的，处处都是Spring。我也提倡J2EE without Spring，但是不是说不用Spring，而是说你写的代码不应该偶合到Spring上去，只有做到了你的代码完全without Spring了，你才真正用好了Spring。

我还没有拔高到这种思维考虑过。。。以前曾经处于好玩，在同一个项目中配置了spring和hivemind，只使用到了IoC、DI以及Hibernate。。。实际上，如果单单从IoC和DI来说，spring和hivemind的bo、dao、service是可以通用的。但是一旦交给容器来管理hibernate，spring和hivemind的事务实现就不一样了。同样AOP的实现也不一样。

如果要完全避免耦合，单独自己实现hibernate事务管理，AOP用第三方框架比如AspectJ等等，的确可以完全不需要import Spring的API，但是不得不去依赖其它框架，那么加入又不想依赖Aspect怎么办呢？或许只有像自己实现hibernate事务管理一样，自己又去实现AOP。。。但是那样一来，我不是对自己的代码没有信心，而是是否有必要重复“造轮子”？。。。。做到最后，hibernate事务自己实现，AOP自己实现，干脆连IoC、DI也自己实现算了，呵呵，说不定最后一口气弄了一个自己的框架出来。。。

从项目的角度来说，项目开启的时候，就会选定技术架构，几乎不可能像我自己弄着耍那样说变框架就变框架，实际上项目启动的那一刻起，就决定了架构的高耦合。。。

我需要再仔细思索Robbin的话，从个人技术来说，看完Robbin的话，既觉得有趣，又觉得混乱。

Spring本身也是模块化的，你不一定要都用。最核心的是IoC容器，最不应该产生依赖的也是IoC容器。正如ajoo说的，IoC容器和其他部分是正交的，只负责对象组装，你可以试试看用ajoo的nuts替换掉Spring IoC容器，去组装你那些Spring bean，Service，DAO，AOP，完全可以的。同样的道理适用任何合格的IoC。Spring除了IoC容器之外，其他的AOP组件，一大堆工具类其实都不依赖于Spring IoC容器，你也可以试试用Hivemind去组装Spring的事务管理功能。

这是一种程度的解除依赖关系，你可以依赖一些Spring的工具类，但是你不必依赖Spring的IoC容器。这是任何用Spring做项目起码的要求。如果做不到without spring ioc container，那根本就是spring没有入门。

如果其他的底层设施提供了更好的管理方式，你可以更进一步，完全without spring api。例如Spring/Hibernate架构的项目，你就可以完全不import spring API。看看DAO示例：

import org.hibernate.SessionFactory;
import org.hibernate.Session;

public class XXXDaoHibernateImpl {

    private SessionFactory sessionFactory;
    public setSessionFactory(SessionFactory sessionFactory) {
        this.sessionFactory = sessionFactory;
    }

    public void addXXX(Serializable xxx) {
        Session session = sessionFactory.getCurrentSession();
        session.save(xxx);
    }
    .... other Dao methods
}

这是一个标准的DAO实现类，由于Hibernate提供了从容器获取Session的API，所以整个持久层脱离了Spring API的依赖，甚至session都无需关闭，只要DAO在事务里面运行，就会在事务提交之后被自动关闭。

这个DAO实现类你也可以把他用在JBoss EJB3容器里面，所不同的就是更换配置文件。这种程序你虽然在Spring环境下编写调试，但是已经完全without spring了。

你一说这个，我想起前几天偶尔想到的一个想法。

一般来说，一个具体项目（公司的财务管理系统，比如说），真正做具体事情的是你的那些entity bean, business logic什么的。不过，在一个分层良好的系统，真正有难度的，技术上有价值的，倒是ejb container, java compiler，aspectj compiler，spring这些不做“实事”的东西。

类比一下，我们这些技术人员总自以为了不起，那么为什么不自己在家弄台计算机写程序发大财？为什么要让那些不做实事的人管着，让他们拿吃肉，我们喝汤？

有没有可能人家做的是一些和我们使用的纯技术正交的，属于cross cutting concern的更有难度的工作（比如企业运作，资金管理）？

越来越觉得像martin fowler这样的传道者，技术教育家的工作是很有意义的，也是任重道远的。

ajoo有点开窍了

嘿嘿，忙了一天，上来看看，大家讨论的很热烈哦。
只是帖子好像被修改过了。  失去了发贴的原始含义。
说说发这个帖子的原因。我的一些朋友在讨论问题的时候似乎已经定兴认为EJB已经过时，如果仍然使用这样的框架，就成了时下很时髦的人——犬儒主义者。因此有感而发，有了这个帖子。

这分两头说了，有一些人把架子搭好了，剩下的交给其他人去填充就行了，就象使用一门技术一样，最难的不是学不学的会它，而是知不知道有这么一个东西。

搭架子的人搭完了架子，你感觉他闲了，其实他的价值在你的工作中无处不在，所以他当然高你“一等”。

但还有一些人确实是不学无术，但你一样要被他呼来喝去的，这就是另一个方面的问题了。

补充一个看法. 记得without EJB中一段有关DAO设计的观点: 持久层的选择,对DAO层的设计有很大影响. 例如方法的粒度上. 同样,代码级"without Spring"是可以做到的, 但一旦使用了Spring, 它就会对我们的设计产生影响. 虽然项目并没有显式的绑定在Spring上,但可能在无形中依赖在Spring的设计理念上.