session中过多的保存数据不是什么好事.一般在jsp页面中我都会把session选项去掉．

如果你在做电子商务会用到购物车，你可以在这个用户进入第一个action时．把购物车的对象(内有存放数据＼删除数据\得到数据的方法)存放到session中.在用户结账时，调用结账action得到session中的数据，调用业务方法，业务方法再调用对dao完成结账．

我是要否定分布式,而你且说什么,分布式session处理问题.有病

spring不错；能在applet级别的程序都提供容器服务，但是在分布式这里可以说是一个弱点；

而搂主问你的问题就是在纯粹使用spring当容器的程序中，如何更好的处理session信息同步的问题，例如：使用数据库保存session状态（或者称为持久化session）是一种解决方案，但是会增大数据库的压力；

可惜你答非所问，竟然说的是单jvm如何更好的使用session的方式；

没有人把分布式当神，只是我们有的程序要跑在这种环境下的，我们不是不喜欢spring的相对简单，也不是不厌烦ejb的复杂，但是spring在于分布式，异步调用或消息机制上还存在问题；

我想包括搂主在内都一直在致力于写一个能像开始的spring那么简单，又能包含EJB事务处理，分布式，异步等功能的企业级框架；

作为一个技术人员本身将立足点完全置于一个框架或者技术都是非常片面的，更何况这个技术仍然在发展；倒是小兄弟你需要好好看看啊，这里是技术论坛，不要随便说别人有病，显得自己素质不高，大家一起讨论技术，有分歧可以讨论但是你要是变相的问候我或者谁的家人就不好了吧，都文明点，你说呢。

我提的一个话题时Session处理，正如zdbj2ee所提出的那样：

>如果你在做电子商务会用到购物车，你可以在这个用户进入第一个>action>时．把购物车的对象(内有存放数据＼删除数据\得到数据的方法)>存放到session中.在用户结账时，调用结账action得到session中的数据，调用业务方法，业务方法再调用对dao完成结账．

我是要等这个答案，购物车我们会放置到HttpSession中，那么如何放在HttpSession呢？无疑是通过request.getSession等命令或Struts或JSF相关配置，那么你肯定需要一个操作HttpSession的action之类的操作类，那么购物车Model和对购物车的操作Process将是可能是在表现层中MVC中的Controller部分，如果用struts也就是要编制一个action类操作httpSession中的购物车。

但是我们知道，购物车是一个业务Model，对购物车Model的操作也属于建模的一部分，象购物车这样的重要业务模型应该是在业务层实现，而不是表现层。但是因为Spring容器没有提供Session操作，就使得我们在业务容器中实现Session方面得操作，只能使用上述原始方案。

想像一下，如果我们购物车在业务层实现，业务层框架如Jdon Framework提供了Session操作，那么我们几乎所有业务功能都可以在业务层实现，表现层的MVC中的Controller将只成为流程调度，而这些都是可以使用XML配置实现，无需太多代码，JSP页面也是XML格式的标签库。

这样，我们就可以快速开发一个J2EE系统，而不用经常在考虑：哪些放在action中调用，哪些放在业务容器中调用，这种选择很浪费时间，而且Spring这样容器无法提供对HttpSession数据操作，使得以后拓展有关Session操作时，只能将这些POJO从Spring容器中移植出来。

我讲这些，无疑是从开发快速性和功能完整性对Spring一个期望，但是也请他们在功能没有完整之前，不要狂叫without EJB，而且也不要请一些不等实战的高手不要在各种媒体上用繁话似景的理论来误导实战者。

欢迎zdbj2ee提出更多实战中质量高、开发速度快的解决方案，

那就需要在Spring之外有个送Session参数的，这就是现在的这种原始方式。

另外，这里谈的不是简单spring无法操作session这个具体技术问题，而是说明一个设计问题，就象张艺谋的黄土地等农村题材不是谈农村事情，只是一个载体。

在我们设计时（不涉及J2EE/或.net技术细节），我们的业务总有大量有态业务，就象购物车这个业务实例一样，所以，一个完整的开发框架（而不是纯设计框架）是应该完成业务设计的目标的。

现在，只能采取jsp+javabeans下的原始方法，zdbj2ee这样的静态方法其实与使用Spring这样Ioc容器设计目标有冲突，既然使用Ioc微容器，而且这个微容器的生存周期scope是appliation，相当于这个项目范围内的静态，我们就没有理由再使用静态类了，除非一些工具类。

benq的讲法有点没听明白，“业务层框架提供了Session操作”？是指业务层对session对象的引用么，还是指将状态保持做成接口，然后针对HttpSession进行实现，还是怎么样？

to zdbj2ee：
我原来有这样的处理方式：

定义 状态保持器 类簇（这个类簇中包含一个针对http(request,session,application等)的实现），针对此类簇提供工厂，这样就可以跟框架结合是用了，不管是spring,ebj等等都行；
interface SituationHolder

void ShoopCarUtils.add(SituationHolder holder).
void ShoopCarUtils.remove(SituationHolder holder).
List ShoopCarUtils.getAll(SituationHolder holder).

这样我的业务曾面的东西以来于我定义的东西，而不是直接跟servlet包中的接口产生依赖；

在次道歉，看来我现在有点简单问题复杂化的趋势了，总是想的太多。

这两种方式都可以实现，取决于业务层框架是怎么做的，Nanocontainer/EJB/HiveMind/JdonFramework实现方式都不一样。
看这个帖子：

http://www.jdon.com/jive/thread.jsp?forum=61&thread=24771&message=15058436#15058436

另外，你前面提的Session同步或分布式Session复制问题都很重要，这些目前来说是EJB的独特特点，所以EJB是无法轻易在一两年内或喊几句口号就能被完全替代的，它当初诞生是IBM/SAP等大型软件公司的经验累积啊。

简单来说，我只是不再让业务类直接依赖于HttpRequest,而依赖与自定义的一个接口，此接口下有一实现类依赖于HttpRequest，也就是说我的业务类不依赖HttpRequest，依赖与SituationHolder;

这样我在部署框架的时候就可以将一个依赖于HttpRequest的SituationHolder接口的实现的实例配置到SituationHolder上；

好处：
1。单元测试：做junit时，构建一个不依赖HttpRequest的SituationHolder的实现，就能测试业务类；

2。将状态保持抽象化，可用在多种情况下，而非只为了在Web状态下，例如UI部分。

我决定看看你的JF的源代码，另外我原来在这儿说过一些关于RBAC的话题，之后一直潜水了。