问题:
需要用 entity bean 实现业务领域概念模型。
所谓业务对象,就是包含了业务逻辑和业务状态的对象。在J2EE应用系统中,可以用entity bean 实现业务对象;但是在用entity bean 实现业务对象,会产生一些问题。
第一个问题是,需要决定是使用远程entity bean还是本地entity bean ,远程entity bean 会增加网络负载,所以如果使用不懂就会境地系统的性能。EJB2 技术规范引入了本地entity bean,但对于只支持EJB1.1版本的系统实现来说也就就不可用。有些EJB1.1容器会优化entity bean之间的调用;但是,这种优化时厂商自己的提供的,并不标准。在EJB2.X 的容器中,本地entity bean和它的客户端处于同一虚拟机中,这就能进一步控制系统性能和网络负载。但是还是需要注意,与POJO业务对象相比,entity bean即使处于本地也还不够高效,因为容器还要透明的提供很多优化,另外 ,对于entity bean的每个调用,容器还用提供很多其他的服务,比如安全管理、事务管理等等。
另一个问题是,如何实现entity bean业务对象的持久化存储,当然可以使用“容器-管理持久化”来实现透明的饿持久化,无需自己编写持久化代码。但是,如果有一个以前遗留的持久化实现,或者需要自己的饿持久化机制来实现某些独特的需求,那么CMP可能就不太合适。这样一来,就要实现时BMP,把业务对象保存到数据存储中。
最后,还要考虑一个问题:业务对象的关系使用CMP实现还是使用BMP实现。只有使用了CMP,才能用上CMR,另外CMR还要求所有的entity bean必须是本地entity bean。
约束:
需要避免远程entity bean的缺点(比如网络负载和远程entity bean关系)
需要用定制的或者以前遗留的持久化实现,完成 bean-管理持久化 BMP
在使用entity bean时限业务对象时,需要高效的处理实现对象的父子关系。
需要用entity bean封装并聚合现存的POJO业务对象
需要充分利用EJB容器的事务管理和安全管理
需要把数据库的物理设计对于客户端封装起来
解决方案:
使用符合实体,结合本地的entity bean和POJO,实现业务对象的持久化,复合实体能够把一组相互关联的业务对象聚合为粗粒度的entity bean实现。
在J2EE应用系统中,业务对象被实现为父对象或者从属对象。
父对象可以重用、可以单独的部署,它管理自己的生命周期,并且管理他与其他对象的关系。每个父对象可能会包含一个以上的对象,并管理这些对象的生命周期,这些对象称为从属对象。
从属对象不是子对象啊,从属对象可能包含其他从属对象,也可能不包含。在从属对象的生命周期和它的父对象的生命周期之间存在紧耦合。从属对象并不直接暴露给客户端,客户端只能通过父对象访问他们。从属对象并不独立存在,他们的识别和管理都要依赖于父对象。
使用复合entity bean,就能够实现父对象和相关的丛书对象。业务对象的聚合,能够结合互相关联的持久化对象,形成一个粗粒度的系统实现。这样也就可能减少应用系统中的entity bean的数量。
在EJB1.1的规范中,entity bean只能实现为远程对象。这就意味着要面对各种分布式组件的常见问题,其中主要包括网络负载和对象粒度。在这种情况之下,应该吧父对象实现为一个远程的entity bean,把从属对象实现为POJO。如果把从属对象也实现为entity bean,那可不高明,因为这会降低应用系统的性能,之所以如此,是由于如果entity bean之间存在父子关系,那么这些这些entity bean之间的通信就会增加网络负载。
在EJB2 版本中,即可以巴entity bean实现为远程对象,也可以实现为本地对象。使用EJB2实现entity bean的时候,应该以本地entity bean的形式实现父业务对象。至于从属对象,则可以为POJO(和EJB1一样),也可以为本地的entity bean。而业务对象和从属对象之间的关系,用样既可以使用BMP,也可以使用CMP,如果用CMP实现,那么从属对象就不能使POJO,只能是本地的entity bean。
为了实现业务对象的持久化存储,必须选择是BMP还是CMP,一些新的应用系统会使用于EJB2兼容的容器。CMP越来越受到这系统欢迎。虽然EJB2的CMP比EJB1要复杂的多,但是它也并不能总能符合性能上的需求,而且可能还有一些特殊的需求,或者已经有遗留的持久化方案,这样就没有使用CMP满足需求了,在这些需求下,必须采用BMP来实现持久化。
使用复合实体,能够在应用系统中充分利用entity bean的优势和EJB架构的一些强大功能,比如容器的事务管理、安全和持久化等。
无论使用远程对象还是本地对象实现复合实体,都不应该直接把entity bean暴露个客户端,应该把所有的entity bean封装在会话门面的背后,让客户端访问会话门面,会话门面在于幕后的相关的复合实体交互。
有些时候应用系统的业务逻辑交互很少,业务逻辑很简单,这样可能就会直接把复合实体暴露给客户端,但是这样做的时候应该注意,因为如果应用系统相复杂方向发展,就会遇到诸如系统可维护性之类的问题。
效果:
1、增加了可维护性
如果使用复合实体模式,把业务对象中的父对象实现为entity bean,从属对象则实现为POJO,那么就能够减少细粒度entity bean的数量,如果使用EJB2,可以把从属对象也实现为本地entity bean,以便于EJB的其他性能,比如CMP和CMR,这样就能够提高系统的可维护性。
2、提高了网络性能
把业务对象中的父对象和从属对象聚合聚合成数量较少的粗粒度entity bean,在EJB1的环境下能够提高系统的整体性能。这种做法能降低网络负载,因为他消除了entity bean之间的通讯。对与EJB2,用本地entity bean把业务对象实现为复合实体,也具有这样的优点,因为这样一来所有与entity bean的交互都与客户端同处于本地了。但是记住,即使是本地部署,也不如POJO高效,因为EJB容器还要负责entity bean的生命周期、安全性、事务管理等服务。
3、减少了对数据库方案的依赖
复合实体为数据库中的数据提供了一种对象化的视图。这样数据库方案对客户端是隐藏的,因为entity bean与数据库方案之间的映射被封装在复合实体中,对数据库修改可能会要求修改复合实体entity bean,但是客户端并不会受到影响,因为复合对象没有把数据库方案暴露给外界。
4、增大了对象粒度
使用复合实体,客户端通常就只需要父对象寻址,而不必定位大量细粒度的从属entity bean。父对象对于从属对象起到了门面作用,暴露一个较为简单的接口,隐藏了从属对象的复杂性。复合实体避免了从属对象细粒度方法的嗲用,降低了网络负载。
5、简化了复合传输对象的创建
复合实体能够创建一个包含了改entity bean以及从属对象的所有数据的复合传输对象,而且只需一个方法电泳,就能够把这个传输对象返回给客户端。这减少了客户端和复合实体之间的远程调用词次数。
需要用 entity bean 实现业务领域概念模型。
所谓业务对象,就是包含了业务逻辑和业务状态的对象。在J2EE应用系统中,可以用entity bean 实现业务对象;但是在用entity bean 实现业务对象,会产生一些问题。
第一个问题是,需要决定是使用远程entity bean还是本地entity bean ,远程entity bean 会增加网络负载,所以如果使用不懂就会境地系统的性能。EJB2 技术规范引入了本地entity bean,但对于只支持EJB1.1版本的系统实现来说也就就不可用。有些EJB1.1容器会优化entity bean之间的调用;但是,这种优化时厂商自己的提供的,并不标准。在EJB2.X 的容器中,本地entity bean和它的客户端处于同一虚拟机中,这就能进一步控制系统性能和网络负载。但是还是需要注意,与POJO业务对象相比,entity bean即使处于本地也还不够高效,因为容器还要透明的提供很多优化,另外 ,对于entity bean的每个调用,容器还用提供很多其他的服务,比如安全管理、事务管理等等。
另一个问题是,如何实现entity bean业务对象的持久化存储,当然可以使用“容器-管理持久化”来实现透明的饿持久化,无需自己编写持久化代码。但是,如果有一个以前遗留的持久化实现,或者需要自己的饿持久化机制来实现某些独特的需求,那么CMP可能就不太合适。这样一来,就要实现时BMP,把业务对象保存到数据存储中。
最后,还要考虑一个问题:业务对象的关系使用CMP实现还是使用BMP实现。只有使用了CMP,才能用上CMR,另外CMR还要求所有的entity bean必须是本地entity bean。
约束:
需要避免远程entity bean的缺点(比如网络负载和远程entity bean关系)
需要用定制的或者以前遗留的持久化实现,完成 bean-管理持久化 BMP
在使用entity bean时限业务对象时,需要高效的处理实现对象的父子关系。
需要用entity bean封装并聚合现存的POJO业务对象
需要充分利用EJB容器的事务管理和安全管理
需要把数据库的物理设计对于客户端封装起来
解决方案:
使用符合实体,结合本地的entity bean和POJO,实现业务对象的持久化,复合实体能够把一组相互关联的业务对象聚合为粗粒度的entity bean实现。
在J2EE应用系统中,业务对象被实现为父对象或者从属对象。
父对象可以重用、可以单独的部署,它管理自己的生命周期,并且管理他与其他对象的关系。每个父对象可能会包含一个以上的对象,并管理这些对象的生命周期,这些对象称为从属对象。
从属对象不是子对象啊,从属对象可能包含其他从属对象,也可能不包含。在从属对象的生命周期和它的父对象的生命周期之间存在紧耦合。从属对象并不直接暴露给客户端,客户端只能通过父对象访问他们。从属对象并不独立存在,他们的识别和管理都要依赖于父对象。
使用复合entity bean,就能够实现父对象和相关的丛书对象。业务对象的聚合,能够结合互相关联的持久化对象,形成一个粗粒度的系统实现。这样也就可能减少应用系统中的entity bean的数量。
在EJB1.1的规范中,entity bean只能实现为远程对象。这就意味着要面对各种分布式组件的常见问题,其中主要包括网络负载和对象粒度。在这种情况之下,应该吧父对象实现为一个远程的entity bean,把从属对象实现为POJO。如果把从属对象也实现为entity bean,那可不高明,因为这会降低应用系统的性能,之所以如此,是由于如果entity bean之间存在父子关系,那么这些这些entity bean之间的通信就会增加网络负载。
在EJB2 版本中,即可以巴entity bean实现为远程对象,也可以实现为本地对象。使用EJB2实现entity bean的时候,应该以本地entity bean的形式实现父业务对象。至于从属对象,则可以为POJO(和EJB1一样),也可以为本地的entity bean。而业务对象和从属对象之间的关系,用样既可以使用BMP,也可以使用CMP,如果用CMP实现,那么从属对象就不能使POJO,只能是本地的entity bean。
为了实现业务对象的持久化存储,必须选择是BMP还是CMP,一些新的应用系统会使用于EJB2兼容的容器。CMP越来越受到这系统欢迎。虽然EJB2的CMP比EJB1要复杂的多,但是它也并不能总能符合性能上的需求,而且可能还有一些特殊的需求,或者已经有遗留的持久化方案,这样就没有使用CMP满足需求了,在这些需求下,必须采用BMP来实现持久化。
使用复合实体,能够在应用系统中充分利用entity bean的优势和EJB架构的一些强大功能,比如容器的事务管理、安全和持久化等。
无论使用远程对象还是本地对象实现复合实体,都不应该直接把entity bean暴露个客户端,应该把所有的entity bean封装在会话门面的背后,让客户端访问会话门面,会话门面在于幕后的相关的复合实体交互。
有些时候应用系统的业务逻辑交互很少,业务逻辑很简单,这样可能就会直接把复合实体暴露给客户端,但是这样做的时候应该注意,因为如果应用系统相复杂方向发展,就会遇到诸如系统可维护性之类的问题。
效果:
1、增加了可维护性
如果使用复合实体模式,把业务对象中的父对象实现为entity bean,从属对象则实现为POJO,那么就能够减少细粒度entity bean的数量,如果使用EJB2,可以把从属对象也实现为本地entity bean,以便于EJB的其他性能,比如CMP和CMR,这样就能够提高系统的可维护性。
2、提高了网络性能
把业务对象中的父对象和从属对象聚合聚合成数量较少的粗粒度entity bean,在EJB1的环境下能够提高系统的整体性能。这种做法能降低网络负载,因为他消除了entity bean之间的通讯。对与EJB2,用本地entity bean把业务对象实现为复合实体,也具有这样的优点,因为这样一来所有与entity bean的交互都与客户端同处于本地了。但是记住,即使是本地部署,也不如POJO高效,因为EJB容器还要负责entity bean的生命周期、安全性、事务管理等服务。
3、减少了对数据库方案的依赖
复合实体为数据库中的数据提供了一种对象化的视图。这样数据库方案对客户端是隐藏的,因为entity bean与数据库方案之间的映射被封装在复合实体中,对数据库修改可能会要求修改复合实体entity bean,但是客户端并不会受到影响,因为复合对象没有把数据库方案暴露给外界。
4、增大了对象粒度
使用复合实体,客户端通常就只需要父对象寻址,而不必定位大量细粒度的从属entity bean。父对象对于从属对象起到了门面作用,暴露一个较为简单的接口,隐藏了从属对象的复杂性。复合实体避免了从属对象细粒度方法的嗲用,降低了网络负载。
5、简化了复合传输对象的创建
复合实体能够创建一个包含了改entity bean以及从属对象的所有数据的复合传输对象,而且只需一个方法电泳,就能够把这个传输对象返回给客户端。这减少了客户端和复合实体之间的远程调用词次数。