session数据完全可以放在web层的session对象中.
在一个项目中应保持session中数据的最少化.我在做这两个项目时,保存在session中的数据只有登录用户的基本信息和一些安全数据.

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

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

看不下去了,哥们,你没弄明白斑竹是问你分布式解决session数据共享的问题么?
或者我描述的简单点,机器1与机器2分享同一个session数据。
真郁闷。

我们现在讨论的是如果处理session问题,谁说是分布式session问题,你把我上面的贴子看明白了,一些无知的人,把分布式当为神.

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

我就在把问题描述清楚点,当处在服务器集群下的一台机器出现问题时,其它机器需要将他正在处理的session接手处理;因此也就涉及到session分享问题,这也是spring等轻量级框架没有考虑到的问题;

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提出更多实战中质量高、开发速度快的解决方案,

我这样使用
void ShoopCarUtils.add(HttpServletRequest request).
void ShoopCarUtils.remove(HttpServletRequest request).
List ShoopCarUtils.getAll(HttpServletRequest request).
这样的操作不复杂吧.这个Utils类,是有依赖性,它依赖于request,但SFSB就没有依赖吗。EJBHOME,EJBOBJECT,JNDI一堆对象。

那么既然spring无法操作session,为什么不把session中的购物车对象作为参数传递给spring中的业务对象呢?

>那么既然spring无法操作session,为什么不把session中的购物车对象作为参数传递给spring中的业务对象呢?

那就需要在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包中的接口产生依赖;

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

朋友,详细说一下你的这个类.
我觉的,不用HttpRequest是不可能的.不管是继承,还是依赖.

>业务层框架提供了Session操作”?是指业务层对session对象的引用么,>还是指将状态保持做成接口,然后针对HttpSession进行实现,还是怎么>样?

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

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

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

to zdbj2ee:

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

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

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

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

to banq:

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

哈哈,所谓EJB重的问题已经没有了,我现在在用EJB3。0开发,感觉就是好,已经从EJB中分出来,叫JPA,确实不错。既可以放到容器里运行,也可以在外面运行。好用啊,大家都试着用用,再也没有什么必须实现这个哪个接口了等等。

我想出了一处理session和web层藕合个方法。
加一个过滤器。负责处理从request得到session然后,保存在threadLocal中,这样在业务层中就可很简单处理session了。