J2EE中的业务逻辑和数据库访问决策说明 - 编程入门网

决策2：封装业务逻辑

前面几章，我没有提及如何组织业务逻辑。你必须决定业务逻辑有什么样的接口。业务逻辑的接口由一些数据和方法组成，这些数据和方法由表示层来调用。在设计接口时重点需要考虑的是：应该封装哪些业务逻辑的操作，而哪些操作不应该显示给表示层。封装接口可以提高程序的可维护性，因为通过隐藏业务逻辑的操作细节，可以实现修改业务逻辑而不影响表示层。缺点是，你必须为封装业务逻辑而特意的写很多的代码。

你还需要考虑其他重要的问题，比如如何处理事务处理，安全，和远程调用问题。通常这些也是业务逻辑接口要负责的问题。为了保证数据的连贯性，业务层的接口必须保证每个事务处理中的调用都能执行。同样，也要验证调用者是否有权限调用业务方法。业务层接口还要负责处理一些远程客户端的问题。

来考虑一下选项。

EJB session faç;ade

经典的J2EE解决方案是：用EJB来封装业务逻辑-基本的session facade.EJB容器提供事务处理管理，安全，分布式事务处理和远程访问。Facade方式可以通过封装业务逻辑来提高程序可维护性。粗糙型(Coarse-grained) API通过减少表示层对业务层的访问次数，而提高性能(因为它将对各个业务流程的处理再封装了一次，所以对底层的业务流程来说，它的API是比较粗糙的，这里也许翻译的不好。请大家见谅)。因为减少调用的次数，可以减少对数据库事务处理的次数，还可以提高对象在缓冲区的机会。如果表示层通过远程访问业务层，则这种API还可以减少网络负担。图表4给出了一个EJB-based session facade的例子。

Figure 4. Encapsulating the business logic with an EJB session faç;ade

在这种设计模式中，表示层也许是通过远程来调用facade(相当于session的一个高级接口)，EJB容器从facade中得到这个调用，并验证调用者的权限，然后开始一个业务处理。这个时候facade调用底层的业务对象，而这些业务对象负责实现具体的业务逻辑。等Facade返回后，EJB容器提交业务处理或者让该业务处理循环等待。

不幸的是，使用EJB session facade有一些严重的缺点。比如，EJB的会话bean只能在EJB容器中运行，这样就托慢了开发和测试周期。另外，如果用EJB2，则用来向表示层传输数据的数据传输对象的开发和维护就会变的很枯燥而且旷日持久。

J2EE中的业务逻辑和数据库访问决策说明(3)

POJO facade

对于许多程序来说，更好的实现途径是用POJO facade和AOP协作。比如负责管理事务处理、表示层的连接和安全问题的Spring 构架。POJO facade对业务层的封装风格和EJB facade很相似，通常也可以用一样的公共方法。而POJO和EJB关键区别是用POJO代替了EJB，用AOP提供的服务(例如业务处理管理和安全机制)替代了EJB容器。表5中，显示了用POJO facade的例子。

Figure 5. Encapsulating the business logic with a POJO faç;ade

表示层调用POJO facade， POJO facade 调用业务对象。和EJB容器截获EJB facade方式一样，AOP通过“拦截机”来截获POJO facade，并验证调用者的权限，然后开始提交业务处理或让该业务循环等待。

通过在应用程序服务器外部开发和调试业务逻辑，对POJO facade的开发可以变的很简单，同时还可以获得许多EJB中会话Bean的好处，比如声明事务处理和安全。关键是，你可以少写点代码。你可以避免写数据传输对象类，因为POJO facade可以将对象域直接反馈给表示层;你可以使用依赖注射的方式来将应用程序组装起来，而不用在为JNDI写查找代码了。

然而，有些时候不能那用POJO facade，比如它不能参与到远程客户端建立的分布

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!