浏览 5089 次
锁定老帖子 主题:有状态业务对象 VS 无状态业务对象
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2004-09-08
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2004-09-09
Expert One-on-One™ J2EE™ Development without EJB™
引用 Stateless or Stateful?
Service objects will usually be stateless. Stateless service layers are highly scalable: They pose no replication issues and there is no need to allocate additional resources for every client. (Remember that one of the key motivations of a middle tier is to share resources between multiple clients.) It is also much easier for stateless service layers to support remote clients, if necessary. The traditional stateless service objects in J2EE applications are stateless session beans (SLSBs). I’ll use SLSBs as a starting point for discussion because they illustrate many of the basic concepts of stateless service objects, which predate EJB. A stateless service layer is one concession of object orientation that I find not too painful. Stateless service objects are semi-objects. Although they cannot expose state to callers, they can hold internal state and they can fully participate in inheritance relationships. If they are local, rather than remote, they can use true objects as parameters and return values. There are two main potential models for stateful service layers in J2EE: stateful session beans (SFSBs) and web tier session objects. If we don’t use stateful session beans, session data is usually held in Servlet API HttpSession objects. Holding session data in the web tier is usually more scalable than holding it in the EJB tier. (See Chapter 10 of Expert One-on-One J2EE Design and Development for detailed discussion of state replication issues.) “Thick” clients such as Swing applications will normally hold their own state. Because stateless service layers have proven their value in numerous technologies, including both J2EE and Microsoft platforms, we’ll focus on them in this book. If possible, design applications to use a stateless service layer. Hold state in the web tier, rather than in the business logic tier, if possible. |
|
返回顶楼 | |
发表时间:2004-09-09
在Patterns of Enterprise Application Architecture一书中对状态有较好的分析,可以参考Chapter 6. Session State
|
|
返回顶楼 | |
发表时间:2004-09-20
Session bean这类重量级玩意儿尽量不要使用状态(EJB 3rd里讲的)。
|
|
返回顶楼 | |
发表时间:2005-03-13
对于EJB来讲,Bean实例并非使用时创建,而是实现创建一个对象池,当client需要该bean中方法时,如果时无状态的,容器会随便指定一个空闲的给client使用,但是如果是有状态的,容器必须记住上次是那个bean实例为这个client服务的,下次同一个client请求也必须由这个同一个实例来服务,不能换由其他的bean实例来服务
|
|
返回顶楼 | |
发表时间:2005-03-13
sunsonbaby 写道 对于EJB来讲,Bean实例并非使用时创建,而是实现创建一个对象池,当client需要该bean中方法时,如果时无状态的,容器会随便指定一个空闲的给client使用,但是如果是有状态的,容器必须记住上次是那个bean实例为这个client服务的,下次同一个client请求也必须由这个同一个实例来服务,不能换由其他的bean实例来服务
sunsonbaby兄,我记得对于有状态session bean 容器也是随便指定一个空闲的给client使用,只是容器会把该客户上次的状态该赋与给这个刚被分配的instance. |
|
返回顶楼 | |
发表时间:2005-03-14
Stateless bean 我理解的不深刻。
但是我又一个问题,对象不就是,将方法和对象分装在一起么?为什么要将他们分开呢?技术上的原因?我想 “Expert One-on-One™ J2EE™ Development without EJB”作者的原则就是在没有分布式的要求前提下,尽量的简单,也对对象该是怎样的就怎样的,何必一定要弄成staeless的呢?为了对象的实例的重用?现在的jvm配合分代式的垃圾收集方式,创建和消除对象都非常快,对性能的影响不会很大啊 |
|
返回顶楼 | |