简述:
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,通过面向对象分析与设计来提炼我们的商业模型,复杂的业务逻辑和规则,策略等通过我们模型对象之间相互协作来完成,提高重用和封装实现。
- Reusability is reduced and business logic code gets duplicated.
- Bloated procedure implementations that become lengthy and complex.
- Poor maintainability due to duplication and because business logic is spread over different modules.
设计的阶段可以先设计好我们的Business Model(BO),如何使用BO来完成我们的请求和交互等可以交给ApplicationService,这样可以划分它们之间的逻辑,由BO
系统演化比较复杂的时候,重构阶段,我们从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。