ApplicationService与BusinessObject

简述：
ApplicationService（Service Level Object）: 是Business层的Façade,定义层次接口集合，充当应用层边界，通常通过调用DAO和BO来完成相应的职责，不包含相应逻辑。不推荐调用其他ApplicationService！此类关联功能应该通过BO完成。
参考资料：
_Patterns of Enterprise Application Architecture _
_By Martin Fowler等 _
Chapter 9. Domain Logic Patterns

_ _
*BusinessObject(Domain Level Object):*基本的业务实现，可以结合Straegy模式。就是我们的BusinessModel,通过面向对象分析与设计来提炼我们的商业模型，复杂的业务逻辑和规则，策略等通过我们模型对象之间相互协作来完成，提高重用和封装实现。

1. Reusability is reduced and business logic code gets duplicated.
2. Bloated procedure implementations that become lengthy and complex.
3. Poor maintainability due to duplication and because business logic is spread over different modules.
   设计的阶段可以先设计好我们的Business Model(BO),如何使用BO来完成我们的请求和交互等可以交给ApplicationService,这样可以划分它们之间的逻辑，由BO

ApplicationService.
系统演化比较复杂的时候，重构阶段，我们从ApplicationService的逻辑重构提炼出我们的Business Model，即是我们的BusinessObject,这时候是ApplicationService -BusinessObject.

 

ApplicationService

_ ApplicationService represents the main role in this pattern and encapsulates the business logic required to provide a specific service. It can encapsulate a variety of business logic types, such as common logic acting on several BusinessObjects, use case-specific business logic, or logic specific to a particular kind of client or channel type. An ApplicationService can invoke a business method in a BusinessObject or another ApplicationService. Implementing Application Services as POJOs is more common because it enhances reusability of the control logic across different clients and facilitates easy layering of Application Services._

Core J2EE™ Patterns: Best Practices and Design Strategies, Second Edition

By Deepak Alur, John Crupi, Dan Malks

*Business Object(BO):*这是我们的商业模型（概念模型，Conceptual domain model）主要责任在于封装商业逻辑、规则、验证等功能。通过对需求采用OOAD得出的对象模型 用来捕获系统的复杂度，可以借助OO带来的好处，封装和控制需求变化、提高代码重用、增强系统可维护 性，降低 后期升级成本和引入bug几率！需要说明的是Business Model是面向客户端，从外部来看待我们的系统的，往往是OOA阶段发现的，Data Model等是我们设计的产物。产生在OOD阶段。
既然叫做Object,那么它应该有自己的状态和行为，行为是我们商业逻辑，那么它有没有状态？当然有，我们知道状态 有三种、transient state, session state, persistent state,通常我们的persistent state有两种，一种存在数据库中的state,我们通过DO来表示，此类数据是我们的业务数据。另一种是通过其他方式如常量、配置、文件等，它们的作用主要是配置我们商业逻辑、规则等。BO的行为就是对 这三种状态的操作，具体方式有很多，就不一一例举了。
讨论比较多的是我们的DO和BO之间的关系，继承DO为 BO或者 在DO中添加方法称为BO,这样的设计BO和DO是一对一的关系，如果同时操作一个DO集合，就不是很方便了，对简单的Business Model是足够了。这种设计对于复杂一点的Model就很不可取，应该BO中用DO来表示存在数据库中的persistent state，这样DO将作为BO的状态，通过BO行为来操作一个或者多个DO,改变persistent state,现在大家都认识到透明的persistent layer的重要性，我想原因应该就在于此。BO改变了DO，但是它并不关心如何持久化的细节，通过ApplicationService模式结合Declarative Transaction Demarcation可以做Automatic dirty object checking，实现简洁和优美的中间层，分离Persistent Logic和Business Logic,Rules,Validation ,这样做持久化机制不会破坏我们的Business Object Model。