前两者是web开发的结构,其实并没有大的区别,jsp不就是servlet吗,性能上没有区别,只是代码和页面的分离程度问题。
ejb的这种是属于分布式结构了,两者的性质也不一样。
ejb的这种是属于分布式结构了,两者的性质也不一样。
解决方案 »
- struts2 文件上传抛出空指针异常
- apache 怎么连接 tomcat
- 巴巴网的第一天
- Java session 问题
- Struts+Jfreechart 从数据库取数据画曲线
- 打开IE出现6025错误
- Spring新特性的AOP配置头去那里找呢??
- LINUX环境下,在哪个配置文件中设置JAVA_HOME路径
- 谁能吹吹EJB里面的InitialContext都有什么用啊?还有WebLogic里面的用户管理有什么用?
- A<User>和A<Book>是两个类还是一个类? A<User>这种的泛型应该怎么理解?
- 我的axis已经发布成功了,为什么在运行的时候还会报这个错??
- WEBLOGIC8的问题
容器管理的服务。EJB 容器使开发人员不必管理常见的企业功能,如安全性、事务处理、连接合用和外部资源管理。
透明的持久性。实体 bean 为处理持久性提供了两个透明选项。容器管理的持久性(CMP)实体 bean 在容器中自动处理所有持久性语义。bean 管理的持久性(BMP)实体 bean 允许开发人员编写持久性逻辑,但仍然减轻了确保数据完整性和并发性的责任(通过将这些任务分配给容器)。
事务支持。实体 bean 提供了两个事务支持模型。在 CMP bean 中声明事务语义。在 BMP bean 中,开发人员直接实现这些语义。这两种情况中,都是容器管理事务,并确定应该提交给定的事务还是应该回滚它。
基于组件的设计。实体 bean 被设计成自我包含的组件,这些组件使用部署描述符配置,并且不用修改任何代码就可以将它们部署到任何 J2EE 应用程序服务器中。
另一方面,实体 bean 也有四个主要缺点: 设计复杂性。容器管理的服务和自动且透明的持久性为整个应用程序设计引入了复杂性。实体 bean 通常也可以通过会话 bean 来访问,这意味着每个事务至少包含两个企业 bean,而通常会更多。
构建周期很长。一个 EJB 周期(设计/构建/测试/集成/测试/部署)所花的时间比可比的 Java 持久性解决方案多两到三倍。
响应时间。实体 bean 与 bean 实例的粒度相关。因此,开发人员始终面临选择:要么将 bean 按原样装入,而在别的方面解决响应时间长的问题;要么将数据分解成较小的实体,从而创建更复杂的系统体系结构。
资源使用情况。实体 bean 消耗了大量系统资源。