EJB实体Bean在领域模型中的障碍，与POJO的历史起源

用J2EE实体Bean（配合容器管理持久性CMP）实现领域模型存在几处具体障碍。其一，CMP是一种受限的对象间关系映射方式，撑不住复杂领域模型常用的许多模式。其二，实体Bean不应该重进入——即在某个实体Bean里调用其他对象后，那个对象（或它调用的任何东西）不能反过来再调用最初的这个实体Bean——而复杂领域模型经常天然需要重进入，重进入行为本身又很难被检测出来，这道鸿沟迫使一些人干脆规定实体Bean内绝不能再调用别的对象，代价是大大削弱了领域模型的优势。其三，领域模型该用细粒度对象和细粒度接口，而实体Bean（尤其2.0之前的版本）本质是远程对象，细粒度接口的远程对象性能必然低下——解法是在领域模型内部只用实体Bean的本地接口。其四，实体Bean依赖EJB容器和已连接的数据库才能运行，创建和测试的耗时都会因此增加，调试也更困难。面对这些障碍，作者和另外两位同事（Rebecca Parsons、Josh Mackenzie）2000年准备一次演讲时，为”就是普通Java对象，只是没有一个花哨的名字”这件事起了个名字：POJO（Plain Old Java Objects）——POJO领域模型组装简单、创建快、可以脱离EJB容器独立测试和运行，完全独立于EJB（这或许正是EJB厂商不太鼓励这样做的原因）。作者的最终建议是：领域逻辑简单、和数据库关系清晰时，用实体Bean（此时一个实体Bean类基本对应一张表）没问题；领域逻辑复杂、需要继承和策略这类模式时，最好用POJO领域模型配数据映射器。作者本人使用EJB最大的挫折，正是当领域模型复杂到需要考虑架构独立性时，EJB却迫使你同时兼顾领域模型本身和EJB环境的特性。