个人意见, 大家对待J2EE模式有的时候太教条了.
切莫忘记很多J2EE模式是在历史背景和特定语境下产生的. 比如: EJB1.1没有"local interface", 早期的容器又缺少对remote EJB界面的优化, 和早期EJB设计者对于客户端多样性的一些设想.
EJB的初衷是纯粹的构建在RMI上的"地点透明". 这个美好的初衷的前提假设是多样化的客户端类型, 比如 HTML, 独立Swing client, Applet client, Midlet client. EJB1 就建立在这个假设之上. 可是很快大家意识到:
1. 这样做的代价是无区别无止境的marshalling, 从而导致性能恶化.
2. 绝大部分J2EE应用是WEB应用, 而WEB 容器和EJB容器通常在一个JVM之内. 没有必要Marshalling.
3. Swing client, Applet, Midlet和其他客户端可以通过其他途径呼叫EJB, 比如WEB SERVICES, 而没有必要用RMI. 事实上RMI-IIOP往往无法通过放火墙, 而SOAP-HTTP则没有这个问题. 对于广域分布应用, web services比RMI更适合做传输手段. 而WEB SERVICES又是可以部署在WEB容器上的, 和EJB同在一个JVM内.
4. 容器生产者往往采用一些优化措施省略不必要的marshalling. 比如在weblogic上, 即使使用了remote EJB, 如果这个ejb部署在本地(JVM), 那么呼叫操作是不通过Socket进行的, 事实上等同于后来的local interface.
在这些发现的指导下, 第一代"核心J2EE设计模式"的主要目的是抵消EJB1的缺点. 比如 Session Facade, Transfer Object的主要目的在于粗糙通信粒度, 减少 Socket 和 marshalling. 而EJB2标准进一步引入了"local interface". 容器生产商也推荐开发者使用这些模式. 自此, EJB 层 与 WEB 层的"共同部署"作为J2EE模式的核心, 成了天经地义.
问题是: 如果WEB LAYER和BUSINESS LAYER"共同部署"在一个JVM里, 那EJB除了"事物处理"和"容器管理永久化"之外, 还有什么意义?
于是产生了SPRING, 于是产生了HIBERNATE. 在TomCat + Struts + Spring + hibernate的领域里, "Business Tier" 成为一个纯粹的设计概念, 不再具备"物理部署"层面的含义.
可是有些传统J2EE的模式保留了下来. 在一个单JVM系统里: Session Facade 和 Transfer Object 已经不具备性能上的必要性, 而更多地是一个审美取向和习惯做法. 当然, Session Facade作为事物处理的起点(spring)的意义仍然存在.
说这么多废话的意思, 是有时我们容易忘记, 分离"状态"和"方法"的"模式", 是为了一个理由而存在的. 在回答"BO"该不该具备"方法"或者"状态"的时候, 我们似乎更应该关心下面的这些问题:
1. 这个BO是代表"交易事物"的, 还是具有"实体身份"的?
2. 这个BO的界面具备什么语意? 有状态? 无状态?
3. 这个BO和下面的永久层什么界面? 如何绑定?
4. 这个BO的部署有什么物理约束?
5. 这个BO现在和未来的客户端是什么, 在哪里?
个人看法, 对于多数中小型, 单层JVM (横向可以集群, 但是纵向"共同部署"在一个JVM里), WEB表达层和EJB业务层"共同部署"的应用而言, 一个完全作为"业务交易中间数据属性集合"而不具备"业务逻辑方法"的BO属于杀鸡的钝牛刀. 原因如下:
1. 没有必要剥离"状态"和方法. "业务逻辑对象"的客户在这个环境里肯定是同一个JVM里, 作为WEB代理的的"SessionFacade", 作为Service代理的ApplicationService, 或者其他复合BO. 在"共同部署"前提下, 它们与BO之间的通信是纯JAVA方法调用. 从性能角度分析, 不必用"无状态"的设计原则来优化通信粒度. 事实上, Core J2EE Pattern里BO的第一个战略"composite entity strategy"也推荐使用 local entity bean 实现BO.
2. 从降低偶合角度看, 复杂数据结构而不具备相应逻辑方法的对象是难以使用的. 可以想象, "业务逻辑对象"的客户程序将需要复杂的代码来维护这个BO的数据完整性. 这样的设计极大地增加了客户程序和业务逻辑对象之间的偶合度.
相反, 如果BO和业务逻辑对象合而为一, 那么BO本身可以负责自身属性数据的检验. 比如, 可以用有限状态模式来设计BO, 既增加BO界面的一致性, 也降低客户程序的复杂度.
EJB3, AJAX, XAML, XUL, 还有其他平台和客户端技术的出现, 应该让我们不断质疑和反思现在"传统"和"模式". 跟随"模式"是不可能有创新的.