>负责处理从request得到session然后，保存在threadLocal中
Spring的安全登录框架Acegi原理上也是这么做的，不过怎么说，这些都需要额外代码（看看Acegi复杂源码即知道），Spring作为一个开发框架，将Session推卸给应用者完成，总是有些说不过去的。

关于threadLocal可以参考这个帖子：
http://www.jdon.com/jive/thread.jsp?forum=121&thread=24664

我已经实现了，在业务对象中无依赖的处理session数据。

业务框架包中
ISession接口
SessionFactory工厂
web框架包中
SessionFilterServlet类，得到请求session存放到ThreadLocal中
HttpSessionImpl实现ISession，依赖于HttpSession，由外部注射。

也有不好的地方，要求必须有这个过滤器层。再有你还要分析为了session加入这个SessionFilterServlet是否有必要。

偶的个人感觉是如果是普通的web项目（servlet+javabean）使用spring肯定是比EJB要方便的多，成本也会少了很多；如果是分布式的企业级应用，那还说啥了，EJB上吧。

to zdbj2ee :
你别折腾了，等2.0吧。今天翻到可能是老外的一篇文章，和我以前意思谈得一样,两个意思，正如我之前指出一样：

1. Spring不是Auto-wiring的。HiveMind/Jdon Framework则支持
2. Spring 1.X不支持持HTTP request和session的。那么Spring的用户在整个期间里都做了些什么？它们在使用数据库替代Session，所以他们只用了Spring的型，反而忘记其魂！Jdon Framework支持Session

全文如下：

我为什么没有使用Spring

在这里，Spring指的是Spring开发框架，一种依赖注入容器的实现。首先，我声明我没有一点冒犯Rod的意思（你是个优秀的人）。但是坦白地说，我不能狂热的追随您的开发框架。更为严重的是，我注意到，我所考虑的这些可能对于Spring框架的使用率来说是危险的，并且有可能降低对Spring框架的使用率。我读到一个关于Spring的很重要的文章或书籍，看起来好像除了我，所有的人都喜欢Spring。但是我有什么损失吗？可能采用Spring是J2EE一个类似“膝跳反射”的事情（这种事情可以不经过大脑）。“J2EE不是好东东，Spring的人说他们的产品更好一些，所以Spring一定是好的”但是事情并不是那样的。


第二点，我仅仅讨论Spring，而不讨论依赖注入。我喜欢依赖注入，并且每天都使用它。它是一个摆脱service locators的好方法。

我记不得有多少次有开发者对我说，“我的上一个项目使用了Spring，这个框架真好”。但是没有人能清楚明白的说出他们究竟喜欢Spring的哪一点，Spring到底帮助了他什么。所以我敢说，他们喜欢setter注入，这使得他们的代码更加灵活和可测；但并不一定必需Spring。我猜有些人并没有彻底理解依赖注入，所以他们依赖Spring来帮助（或者强迫？）他们使用依赖注入。然而，这种好处并没有在量上大于Spring在你的代码上带来的负面影响，这些负面相应在下面的清单上。

Spring的狂热者公开的指责J2EE，但是从他们的指责中，我可以说，Spring实际上既不是轻量级也不简单。Javadocs未必是必要的，但是这一切都要怪罪于一个用户API吗？最起码J2EE清晰的将API和它们的实现分离开来。Spring的鼓吹者吹捧Spring不会“动”你的代码，例如，你不必去实现任何的Spring指定的接口（生命周期接口除外等等）。新闻特写，“XML配置文件是我们自己的代码，通过它，我们能组织起很多的代码，这些代码都是Spring给定的”

为什么我一定要把我所有的依赖使用XML文件来表达？我是需要把我所有的对象都用Spring来处理，还是仅仅一些没有考虑成熟的？上面我所说的这些问题，Spring文档没有给出一些可靠的答案，而且所有的Spring书籍也没有给出。我假定我们使用Spring是为了产生所有的对象。那么这样还是我们喜欢的Java编程吗？我希望在编译期和随后的装载期能够确定这些对象，而不是在运行我的代码的时候才能够确定。Spring能做到支持这些吗？

很明显，我希望装载一些像JDBC驱动这样的动态实现的依赖（即不要求编译期的检测）；但是在我的系统中，这样的依赖只是一小部分；而剩下的部分，我们代码的绝大部分却不是。我是在使用一种强类型的语言。如果我希望像Spring那样，我会使用Ruby。难道Spring的配置文件不像是我们在猜测着将Java代码写入XML文件里吗？难道那些使用Spring的开发者使用起Java来不那么舒服？我确信增加了一个XML层并不能使得代码变得哪怕是一点点简单。

现在回过头来谈谈关于对Spring API的依赖的问题。我不得不调用容器来产生我的第一个对象（假定剩下的Spring管理对象是注入的），不是吗？我需要一些方法在编译期间来测试我所请求的对象是正确的类型；我不想靠抛出违例的方法。究竟，我真的需要一个容器吗？在Spring里，你通过使用一个唯一的ID来获取对象。我假定大部多数的开发者在他们Java代码里使用一个String类型的常量来定义他们的ID。Spring并不能帮助我使得我的Java代码里的ID值和我的XML文件里的ID值保持一致。当一个对象已经够用了的时候，为什么要使用两个对象？是否我们真的把所有的信息组织到一起放到了容器里？是Java的包和类不够用了吗？

还有一个困扰我的问题是，在我的XML配置文件里，我不得不引用Spring实现的类，我不想管这些东西。在Spring的计划里，我听说更加简单的、域范围的XML将在2.0版本中被使用，但是我到现在还没有看到。为什么这些不能早一点被采用呢？

什么继承上的东西啊？关于超常类名置换的变换。但这些都不是我的风格。

Spring在哪里支持了JDK1.5的泛型？我知道你有很多客户运行在JDK1.4甚至JDK1.3的版本上，但是这和JDK1.5没有分歧啊。泛型打开了通向像这种框架的各种各样的可能性的大门。这些是我最喜欢的JDK1.5的新特性，拥抱这些新特性吧！

你曾经看过每次你产生一个对象Spring要做多少事情吗?我需要在运行期内有少量的instanceof，而大多数是在装载期的Class.isAssignableFrom()。不是因为内部的实现给最终用户带来了很多的麻烦，而是因为把它作为了一个测试框架剩下部分质量的试金石。一个好的对于bean的创建渠道的重构将会很容易的被遵循和产生更加高质量的代码，并且不需要求助于更多的继承就能被重用。

Auto-wiring也有同样的问题。每一个人真的在使用它吗？或者是为未来的重要功能的一个铺垫？
　　Spring是怎么处理领域范围的？我听说在2.0版本中，Spring最终会支持HTTP request和session的。我很惊讶难道现在这些没有被支持吗，那么Spring的用户在整个期间里都做了些什么。难道是新的版本将使我能够定义自己的领域范围？例如，它将实现我想要一个“conversation”领域范围，就像Seam将要支持的那样。

我们将不涉及MVC或者AOP框架。幸运或者不幸的是在某一时候，我将不使用一个依赖注入容器。难道不认为PicoContainer已经远离了简单二字。它也和Spring有同样的问题，我认为Aslak和Jon已经转移到了Ruby的领地。还有其他的开发框架没有这样的问题吗？

幸运地，简单的采用依赖注入设计模式能让你完成Spring的90%的工作，特别是当你在并不急于使用它的时候。这是我推荐的方法。我的确没有看到让我自己马上使用Spring的理由。没有它我工作的很好。如果你在使用它，那么请你把眼睛睁大一些，使用怀疑的、鉴赏的目光。如果仅仅因为某人有流行的开源框架，他们有很好的市场，并且他们被一些大的公司支持（IBM在很多年前就推荐我使用Struts）。但这并不意味着他们知道什么工具对你最好，尽管他们比你知道什么是更好的。


我认为spring框架很好，spring的配置文件有些地点是有些复杂，而这些复杂的配置多体现在使用bean的注射和事务上，这些地点要是可以使用“源注释”可以会好一些，我喜欢我们在一起，谈论一些有针对性的问题，然后大家来解决它，而不是在网上找一篇老外的文章来说明什么。

>我喜欢我们在一起，谈论一些有针对性的问题，然后大家来解决它，而不是在网上找一篇老外的文章来说明什么。

呵呵，误解了，我不是特地找这篇文章，而是搜其他内容正好看到，我的习惯是一个主题讨论尽量更广泛一些，各家观点都有。我目前个人观点是中立，要是一定要我推荐，我推荐我设计的JF。

这里贴一封POJOs in Action的章节，其中一些章节讲得不错，也是碰巧看到的，但是很多词眼非常主观。

比如作者认为传统EJB两个主要问题：
1.The first is that EJBs encourage developers to write procedural-style applications.

2.The second problem is that the cumbersome nature of the development process eveloping with POJOs: faster and easier
when using EJBs doesn’t allow developers to take advantage of many of the best pratices used for “normal” Java development.

我标注的两个黑字，第一个问题说EJB鼓励用户开发过程语言，鼓励这个词语主观性很强，那是不是说java的if else语法也容易使很多用户写出过程性程序，那么就说if else鼓励用户写过程性语言而指责它呢？Annotation容易写入数据库配置，那么是不是就是说Annotation也有鼓励倾向呢？

EJB的第二个问题中用的cumbersome nature（笨重特性），cumbersome 笨重也是一个主观名词，就象本主题开始说的一样，重和轻均是主观感受，100公斤对于你很重，但是对于举重运动员则很轻，所以，指责一个事物使用非常个人主观的词语，就如国人以前假定有罪的推论一样，你首先觉得它有罪，然后就使用主观性词语来描述它，这样的描述不客观。但是这样言论很容易惑众。

看了这篇文章一个章节，觉得有太多言论可以争辩，缺乏理性说服力，所以老外的话并不都是真理，如果有实战技巧可以引用借鉴，如果是纯理论文化描述，则弃之。

http://assets.devx.com/download/15031.pdf


另外关于无论使用什么框架，一个业务系统完成，2/3还是需要我们自己动手手工设计，这是问题关键所在。


我认为以后软件开发在做项目分成三种人,一种框架,一种是业务需求分析,一种是编码.这样才能做出一个好的项目.

我现在也在想"源注释"可能为我们带来,更多的好处.

>我认为以后软件开发在做项目分成三种人,一种框架,一种是业务需求分析,一种是编码.这样才能做出一个好的项目.

是的，这好比一个工厂，框架相当于工厂自动设备；业务需求分析也就是领域建模，相当于产品设计师；编码人员相当于操作自动化设备流水线上的“工人”。

关于“源注释”，　我有时也觉得不够方便，实际我需要的是定义这个Bean的名字，也是就是类的名称，但是将类名称第一个字母小写，例如类的名称是ProductService，那么名称就是productService，使用源注释还是要自己敲入这些字母，一旦敲错如prodcutService就麻烦，找起来不容易。

这点和动态类型语言Ruby on Rails/php一样，没有严格的类型检查，依靠单元测试来发现错误，对于一个稍微复杂项目是恶梦，但是项目往往是不知不觉中变得复杂起来的，所以小中型到大型如果不选择平滑的可伸缩性，而是跳跃式的，最终是害了自己，如果自己还在做这个项目的话。

总之：对于小中大型项目，没有自始自终适合的一套架构设计，但是也不能选择革命推翻式的架构。

和jdon大哥聊的很投愿,多谢.我现在沈阳工作,公司现在已经不在做国内项目了,我的项目基本是最后一个国内项目,而国外的项目基本也没有,公司现在的业务就是把人送到别的公司从中间赚些钱,而我的技术现在是什么程度他们根本也不了解也不关心,工资也是看学历没什么意思.可以说自已孤身一人在公司,一个连可以在一起讨论技术和项目的人都没有,真是有些悲哀.在公司感觉就是有力气没地方用.

自已现在觉的为一有些意思的地方,也就是在工作之余在,在论坛上和大家探讨问题.

在公司服务了三四年了,现在想想是不是应该出去走走了.

在下“入行”已然三年，说到入行，真觉惭愧，至今仍只会写点JSP。
当今业内纷争，不亚于三国内乱。新标准、新技术、新框架层出不穷，粉墨登场。令人不甚惶恐。想来我离入行，还早着呢。
说的远了，不兜圈子了。作为Java程序员，特别是J2EE程序员，EJB必须得学。就好比是练武之人，内功心法是基础，格斗招数是门路。窃以为，学EJB就是练内功，没有十年、二十年那是不会有所成就的，如果急于求成，无疑会走火入魔。张孝祥说过，二十年后内功高手天下无敌！我期待着这一天！
浅闻陋见，包涵包涵！

看到大家在为用EJB还是Spring吐沫飞扬，我也忍不住要说几句，其实任何事物只要存在就一定有存在的理由，也就是说脱离环境，我们无法辨别谁是谁非。
我觉得大家应当多发表一下他们各自适合的场合，而不是抨击谁好谁不好。
EJB存在，尤其是SessionBean他提供了服务组件的思想，可以独立运行，其重用性不仅体现在代码级，同时也在运行级。我认为这是EJB的最大的好处，这也是分布式计算的核心，是谁说分布式计算is nothing?这和否定多层网络体系结构没有任何区别。如果用过CICS，.net等框架，其实不难理解EJB存在的价值。造成大家很少使用EJB的原因是由于目前J2EE框架主要还是应用在企业系统的外围环节，而真正的核心仍然跑在CICS等传统企业应用服务器上，而这些地方正是EJB应该在的位置。
POJO和EJB其实并不一定是竞争关系，他们可以互为补益，EJB的具体实现可以使用POJO, 而EJB为POJO提供分布式计算能力。


不知楼上的这位朋友,在开发ejb时,是怎样发布的测试的,每一次小修改发布一次和测试用例的编写,简单吗?

昏死。
spring只是一个ioc容器，
怎么跟session扯到一起了，
跟EJB更是不沾边。
不要把spring想得那么大，
它只是一个IOC容器而已，
同时能方便集成其它的J2EE关键技术。

我坚信“简洁，方便”才是J2ee开发不二的法宝，这也是j2ee的初衷，EJB的优势“好像有很多，好像很少有人问为什么!”，EJB给人的感觉是：“超稳定；有支持大并发量的优势；集群，异步消息的首选。“
到底容器提供商是为容器本身做了很多工作，还是为EJB做了很多工作？
很多疑问需要破解！
Spring在简洁，方便上吻合了郁闷的程序员的心理，但是它也的的确确在回避很多自己不擅长的方式，也许两年前你说分布式的考虑，异步消息的使用还是80/20原则，但是时代在变，这样的需求在不断增加，我认为这也是spring2.0极力推出的POJO方式的jms消息处理的主要原因，但是接受消息方的多线程处理，事务的分布式控制还有待考察！
总之，我是偏向Spring的，因它给我带来了方便，使我摆脱了劣质的接口调用方式，过度精力的结构配置。EJB3虽然不错，但是无法摆脱商业政治的影响。总之，对于容器的依赖，让开发者也带上了枷锁，Web容器的测试大家也是知道的，何况应用容器的测试，我坚信脱离容器，才是目前各种框架需要解决的当务之急！

上页
下页