EJB的使用
我既做过使用EJB 进行开发的项目，也采用过轻量级方式开发的项目，在没有经验的时候使用EJB是应为EJB看上去能给一个项目提供更宽阔的扩展空间和可靠保障。有经验的时 候就会根据实际项目的规模，时间，人员等众多因素和需要来选择是否使用EJB，什么类型的EJB。首先需要明晰的一个概念就是 EJB != J2EE. EJB之只是J2EE中的一个部分而已。 J2EE包含很多的技术，JSP, Servlet, JMS, JDBC, JAAS, JMX, 和EJBs. J2EE同时也包括了如何一起使用这些技术来构建解决方案的指导和模式(如J2EE Core Design Pattern). 所以使用J2EE本身对开发人员是由一定的技术要求的。
如果你在不需要EJB的地方使用它， 它往往会对你的应用的性能带来一定的损耗。由于本身的额外损耗，它会与你的应用进行资源的竞争，包括CPU, 内存等等。
Plain Old Java Objects, 或者说叫 POJOs, 在Web应用中对于EJB是一个不错的轻量级替代方案， 但是，如果你的应用项目对集群，高可靠性，等企业级运算的要求比较高，应用服务器可以是一个不错的选择，在一般的Web应用中，如果内容发布，管理等等， 一个轻量级的Web服务器或许就可以满足需求。 所以最后的选择还是以需求为重，不要为了使用技术而使用技术。
数据访问
大多数的Web应用除了前端的页面控制外，主要的问题的焦点就集中在了数据访问，应用本身的重点也就是在数据，如果对数据进行了比较好的管理，前端的展现如何千变万化也无妨。
在 一个相对复杂的应用系统中，数据的关系往往是复杂的，可能其中有60%是简单的CRUD操作，可能有40%是复杂的关联操作，从设计之初，可能就需要来考 虑是从对象到关系的设计，还是从关系到对象的设计。从我个人的观点来看，两者是需要同时考虑的， 比如说有些应用的部分只要求高效率的数据存储和传递，这个时候我们可能就需要对数据库表结构进行很多特殊的设计，甚至利用到数据库特有的特性来提高性能， 这种情况下我们就要以关系为主，虽然最终是用过Java对象去操作数据，但本身的重点还是在数据。
I. 小型的应用
Controller --> Business Services Layer (POJOs) --> Data Access Layer
II . 大型的应用
Controller --> Session Facade --> Business Services Layer (POJOs) --> Data Access Layer
如 果你在前期应用的规模还不大的时候开用I的方式进行业务逻辑以及数据的封装，把Business Service作为一个单独的层次封装起来，当你的业务规模增长，需要使用到应用服务器的时候，你只需要在前面加一层EJB(Session Facade)，转化成模型II, 就可以很容易的把旧的应用迁移到新的体系下，而不至于要重新修改原有的业务层，或者整个重写。
在Data Access Layer 你可以使用O/R 工具来提供对数据的透明访问能力，同时对于复杂的关系处理直接采用JDBC操作的方式，都是可以的。
下面的方式或许是一个都能够满足要求的方案
740)this.width=740" border="undefined">
参考: JPetstore 4.0 提供了一个不错的Business Service Layer的设计方案
740)this.width=740" border="undefined">
740)this.width=740" border="undefined">
740)this.width=740" border="undefined">
740)this.width=740" border="undefined">
740)this.width=740" border="undefined">