谈谈我参与的一个企业J2EE项目

         我现在正在进行的一个项目采用的服务器端架构是Stateless Session Bean+Commands+Daos+Hibernate。
        这个项目的技术准备是从2005年5月份开始的，当时我们几个负责服务器端架构设计的人脑子里都没有形成明确的概念。有几个典型的系统问题：事务控制，业 务逻辑，DAO访问逻辑，实例池，是否使用O/R Mapping框架等也都经过了一段时间的讨论，包括业务组件和DAO组件的粒度等等。

       用无状态SessionBean，事务控制可以通过CMT交由应用服务器管理，当然，其实例的pool，应用服务器也能很好地管理。但业务组件呢？如果业务逻辑写在无状态SessionBean里面，当然没有任何问题，而且也契合J2EE规范的定义。但初步的需求咨询得出的结论是：我们的业务系统用例会超过1000个，也就是说，业务逻辑组件将达到数百或超过1000（如果一个业务组件能完成一个用例的话），难道我们要维护数百甚至上千的Stateless SessionBean 吗？众所周知，EJB的开发和部署相对于普通java项目还是要复杂一些的。当时，我的任务是考虑DAO层以下的设计，最初，我想将DAO的方法粒度做细，即每个DAO只完成特定一个数据表的操作，但后来我发现，一个从逻辑上理解很简单的数据操作实际上可能要操作多个数据表的存取。比如，如果一个用户查询的操作，UserDAO需要跟据UserID返回一个完整的用户信息，实际上这个用户信息UserProfile有可能是一个很大的业务实体。包括了用户的基本信息（姓名，性别，职位，工号，部门，电话，地址，邮件等等）以及他的数据权限，功能权限，todoList，提醒列表等等来源于多个数据库表的内容。当然这是个极端的例子，但足够说明在业务组件层和DAO层之间是不可能只通过PO工作的。必须引入复合实体。

        在Stateless SessionBean和DAO层直接引入一层业务逻辑bean成了水到渠成的事，当时我把这一层定义为service层。service层刚引入时，还是个有点暧昧的角色。毕竟，如果业务逻辑在Stateless SessionBean中写的话，那么service只是业务逻辑层和DAO层的一个缓冲，势必是个有点模糊的层。后来，在以为架构专家的建议下，我们引入了command模式，完成业务逻辑，处于Stateless SessionBean和DAO之间。command模式，使我们不必关心每个command的具体入参和出参。而Stateless SessionBean则彻底变成了一个focade。只负责职责commnd的mapping和事务处理。
      
      
      
         当时，我们公司还没有用Hibernate做过大一点的项目，对它的功能，性能等等还存在一定的怀疑。也有同事曾经质疑O/R Mapping是否相比JDBC编程有优势，在经过了一段时间的研究后才决定采用Hibernate做DAO实现。
         当时我负责DAO以下这部分的设计，其实有了Hibernate，DAO的设计也就谈不上什么设计了，只需要将Hibernate包装起来就完了。只是花了点时间研究了一下PO及cfg.xml配置文件的自动生成。由于建模方向还是从数据库到领域对象，我找了个eclipse插件好像叫Hudson的。能够根据数据库表直接生成PO和映射文件。当时的想法也很单纯，因为我们的数据库表会超过200个，其中的部分业务表字段数可能会100个或150个以上，维护如此数量的PO和hbm映射文件，如果靠手工来做显然是不够的。