搜索 | 会员  
常见的架构设计策略
来源: CSDN   作者:  日期:2018-1-24  类别:架构设计  主题:架构设计  编辑:keenboy
目前流行的轻量级JavaEE应用的架构基本比较统一,通常会使用Spring作为核心,向上整合MVC框架,向下整合ORM框架。使用Spring的IoC容器来管理个组件之间的依赖关系时,Spring的声明事务将负责业

目前流行的轻量级Java EE应用的架构基本比较统一,通常会使用Spring作为核心,向上整合MVC框架,向下整合ORM框架。使用Spring的IoC容器来管理个组件之间的依赖关系时,Spring的声明事务将负责业务逻辑层组件的事务管理。当我们决定采用某种架构设计时,我们主要考虑这种架构是否成功地将规范和现实分离了,从而可以提供较好的可扩展性、可修改性。

1.贫血模型

贫血模型是最常用的应用架构,也是最容易理解的架构。所谓贫血,指Domain Object只是单纯的数据类,不包含业务逻辑方法,即每个Domain Object类只包含相关属性,并为每个属性提供基本的setter和getter方法。所有的业务逻辑都由业务逻辑组件实现,这种Domain Object就是所谓的贫血的Domain Object,采用这种Domain Object的架构即所谓的贫血模型。 
贫血的Domain Object实际上以数据结构代替了对象。在贫血模型下,业务逻辑对象作为dao组件的门面,封装了全部的业务逻辑方法,web层仅与业务逻辑组件交互即可,无需访问底层的dao对象。贫血模型背离了面向对象的设计思想,所有的Domain Object并不是完整的Java对象。 
总结起来,贫血模型存在的缺点:项目需要书写大量的贫血类;Domain Object的业务逻辑得不到体现。由于业务逻辑对象的复杂度大大增加,许多不应该由业务逻辑对象实现的业务逻辑方法,完全由业务逻辑对象实现,从而使业务逻辑对象的实现类变得相当庞大。贫血模型的优点:开发简单、分层清晰、架构明晰且不易混淆,所有的依赖都是单向依赖,解耦优秀。

2.领域对象模型

根据完整的面向对象规则,每个Java类都应该提供其相关的业务方法,所以在系统设计更完备的Domain Object对象,则Domain Object不再是单纯的数据载体,Domain Object也包含了相关的业务逻辑方法,提高重用度,将与Domain Object密切相关的业务方法放在Domain Object对象中实现。DAO对象是变化最小的对象,它们都是进行基本的CRUD操作。 
不要在Domain Object中对消息回复完成持久化,如需完成持久化,必须调用DAO组件;一旦调用DAO组件,将造成DAO对象和Domain Object的双向依赖;另外,Domain Object中的业务逻辑方法还需要在业务逻辑组件中代理,才能真正实现持久化。 
领域对象模型主要的问题是业务逻辑组件比较复杂:业务逻辑组件继续需要作为DAO组件的门面,而且还需要包装Domain Object里的业务逻辑方法,暴露这些业务逻辑方法,让Action组件可以调用这些方法。

3.合并业务逻辑对象与dao对象

在这种模型下DAO对象不仅包含了各种CRUD方法,而且还包含各种业务逻辑方法。此时的DAO对象,已经完成了业务逻辑对象所有任务,变成了DAO对象和业务逻辑对象混合体。此时,业务逻辑对象依赖Domain Object,既提供了基本的CRUD方法,也提供了相应的业务逻辑方法。DAO对象和业务逻辑对象之间容易形成交叉依赖(可能某个业务逻辑方法的实现,必须依赖于原来的DAO对象)。当DAO对象被取消后,业务逻辑对象取代了DAO对象,因此变成了一个业务逻辑对象依赖多个业务逻辑对象。而每个业务逻辑对象都可能包含需要多个DAO对象协作的业务方法,从而导致业务逻辑对象之间的交叉依赖。 
这种模型导致了DAO方法和业务逻辑方法混合在一起,显得职责不够单一,软件分层结构不够清晰。而且使业务逻辑对象之间交叉依赖,容易产生混乱,未能做到彻底的简化。

4.合并业务逻辑对象和domain object

在这种架构下,所有的业务逻辑都应该被放在Domain Object里面,而此时的业务逻辑层不再是传统的业务逻辑层,它仅仅封装了事务和少量逻辑,不再提供任何业务逻辑的实现。在这种设计思路下,业务逻辑层变得非常“薄”,它的功能也变得非常微弱。 
在这种设计下,Domain Object必须使用DAO对象直接调用DAO组件的持久化方法,从而使得Domain Object获取容器注入的DAO对象,通过DAO对象完成持久化操作。 
这种架构的优点是:业务逻辑对象非常简单,只提供简单的事务操作,业务逻辑对象无须依赖于DAO对象。但这种架构也存在如下缺点:dao对象和Domain Object形成了双向依赖,其复杂的双向依赖会导致很多潜在的问题;业务逻辑层和Domain层的逻辑混淆不清,在实际项目中,极其容易导致架构混乱;由于使用业务逻辑对象提供事物封装特性,业务逻辑层必须对所有的Domain Object的逻辑提供相应的事务封装,因此业务逻辑对象必须重新定义Domain Object实现的业务逻辑,其工作相当繁琐。

5.抛弃业务逻辑层

抛弃业务逻辑层有两种形式:Domain Object彻底取代业务逻辑对象、由控制器直接调用DAO对象。 
(1)Domain Object完全取代业务逻辑对象 
这种架构设计更加简单,Domain Object与DAO组件形成双向依赖,而web层的控制器直接调用Domain Object的业务逻辑方法。优点是分层少,代码实现简单。缺点是:业务逻辑对象的所有业务逻辑都将在Domain Object中实现,势必引起Domain Object的混乱;Domain Object必须直接传递到web层,从而将持久化API直接传递到web层,因此可能引发意想不到的问题。 
(2)控制器完成业务逻辑 
在这种模型里,控制器直接调用DAO对象的CRUD方法,通过调用基本的CRUD方法,完成对应的业务逻辑方法。在这种模型下,业务逻辑对象的功能由控制器完成。事务则推迟到控制器中完成,因此对控制器的execute()方法增加事务控制即可。 
对于基本的CRUD操作,控制器可直接调用DAO对象方法,省略了业务逻辑对象的封装,这就是这种模式的最大优势。对于业务逻辑简单的项目,这种模型是很好的选择。


德仔网尊重行业规范,每篇文章都注明有明确的作者和来源;德仔网的原创文章,请转载时务必注明文章作者和来源:德仔网;
头条那些事
大家在关注
广告那些事
我们的推荐
也许感兴趣的
干货
了解一下吧