常见SSH的架构设计策略（二）

justin8335

浏览: 28911 次
性别:
来自: 福州

最近访客更多访客>>

影子yingzi

比乙醇还纯OO

stve

fayuandi

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

网摘

SSH 设计模式 DAO Spring Web

Rich Domain Object模式

在这种模式下，Domain Object不再是单纯的数据载体，Domain Object包含了相关的业务逻辑方法。例如News类包含了addNewsView 方法等。

下面是修改后的News类的源代码：

java 代码

public class News extends BaseObject
{
//此处省略了其他的属性
//此处省略了属性对应的setter和getter方法
//增加新闻回复的业务逻辑方法
public NewsReview addNewsReview(String content)
{
//以默认构造器创建新闻回复实例
NewsReview review = new NewsReview();
//设置回复内容
review.setContent(content);
//设置回复的发布日期
review.setPostDate(new Date());
//设置回复的最后修改日期
review.setLastModifyDate(new Date());
//设置回复与消息的关联
review.setNews(this);
return review;
}
//此处省略了重写的hashCode，equals等方法
}

在上面的Domain Object中，包含了相应的业务逻辑方法，这是一种更完备的建模方法。

注意：不要在Domain Object中对消息回复完成持久化，如需完成持久化，必须调用DAO组件；一旦调用DAO组件，将造成DAO对象和Domain Object的双向依赖；另外，Domain Object中的业务逻辑方法还需要在业务逻辑组件中代理，才能真正实现持久化。

在上面的业务逻辑方法中，并没有进行持久化。如果抛开DAO层，这种Domain Object也可以独立测试，只是没有进行持久化。

DAO对象是变化最小的对象，它们都是进行基本的CRUD操作，在两种模型下的DAO对象没有变化。

另外还需要对业务逻辑对象进行改写，虽然Domain Object包含了基本业务逻辑方法，但业务逻辑对象还需代理这些方法，修改后业务逻辑对象的代码如下：

java 代码

public class FacadeManagerImpl implements FacadeManager
{
//业务逻辑对象依赖的DAO对象
private CategoryDAO categoryDAO;
private NewsDAO newsDAO;
private NewsReviewDAO newsReviewDAO;
private UserDAO userDAO;
//...此处还应该增加依赖注入DAO对象必需的setter方法
//...此处还应该增加其他业务逻辑方法
//下面是增加新闻回复的业务方法
public NewsReview addNewsReview(Long newsId , String content)
{
//根据新闻id加载新闻
News news = newsDao.getNews(newsId);
//通过News的业务方法添加回复
NewsReview review = news.addNewsReview(content);
//此处必须显示持久化消息回复
newsReviewDAO.saveNewsReview(review);
return review;
}
}

在Rich Domain Object的模型中，addNewsReview方法将放在News类中实现，而业务逻辑对象仅对该方法进行简单的代理，执行必要的持久化操作。

在这里存在一个问题：业务逻辑方法很多，哪些业务逻辑方法应该放在Domain Object对象中实现，而哪些业务逻辑方法完全由业务逻辑对象实现呢？Rod Johnson认为，可重用度高，与Domain Object密切相关的业务方法应放在Domain Object对象中实现。

业务逻辑方法是否需要由Domain Object实现的标准，从一定程序上说明了采用Rich Domain Object模型的原因。由于某些业务方法只是专一地属于某个Domain Object，因此将这些方法由Domain Object实现，能提供更好的软件复用，能更好地体现面向对象的封装性。

Rich Domain Object模型的各组件之间关系大致如图8.2所示（贫血模式的组件关系图与此类似）。

图8.2 Rich Domain Object的组件关系图

这种Rich Domain Object模型主要的问题是业务逻辑对象比较复杂，由于业务逻辑对象需要正面封装所有的DAO对象，因而难免有大量的DAO方法（基本的CRUD）需要业务逻辑对象封装。业务逻辑对象封装DAO方法主要基于如下考虑：

— DAO对象不应该暴露为Web层。

— DAO对象的DAO方法必须增加事务控制代码，而事务控制则放在业务逻辑层完成。

为了简化业务逻辑对象的开发，Rich Domain Object模型可以有如下两个方向的改变：

— 合并业务逻辑对象与DAO对象。

— 合并业务逻辑对象和Domain Object。

1．合并业务逻辑对象与DAO对象

在这种模型下DAO对象不仅包含了各种CRUD方法，而且还包含各种业务逻辑方法。此时的DAO对象，已经完成了业务逻辑对象所有任务，变成了DAO对象和业务逻辑对象混合体。此时，业务逻辑对象依赖Domain Object，既提供基本的CRUD方法，也提供相应的业务逻辑方法。

下面是这种模式的代码（Domain Object的实现与前面的Rich Domain Object模式一样，此处不再给出）：

java 代码

// NewsServiceHibernate继承HibernateDaoSupport，实现NewsService接口
public class NewsServiceHibernate extends HibernateDaoSupport
implements NewsService
{
//此处添加NewsService对象依赖的DAO对象，以及对应的setter方法
//根据主键加载消息
public News getNews(Long id)
{
News news = (News) getHibernateTemplate().get(News.class, id);
if (news == null) {
throw new ObjectRetrievalFailureException(News.class, id);
}
return news;
}
//保存新的消息
public void saveNews(News news) {
getHibernateTemplate().saveOrUpdate(news);
}
//根据主键删除消息
public void removeNews(Long id)
{
getHibernateTemplate().delete(getNews(id));
}
//查找全部的消息
public List findAll()
{
getHibernateTemplate().find("from News"));
}
//下面是增加新闻回复的业务方法
public NewsReview addNewsReview(Long newsId , String content)
{
//根据新闻id加载新闻
News news = newsDao.getNews(newsId);
//通过News的业务方法添加回复
NewsReview review = news.addNewsReview(content);
//此处必须显示持久化消息回复
newsReviewService.saveNewsReview(review);
return review;
}
}

正如上面见到的，DAO对象和业务逻辑对象之间容易形成交叉依赖（可能某个业务逻辑方法的实现，必须依赖于原来的DAO对象）。当DAO对象被取消后，业务逻辑对象取代了DAO对象，因此变成了一个业务逻辑对象依赖多个业务逻辑对象。而每个业务逻辑对象都可能包含需要多个DAO对象协作的业务方法，从而导致业务逻辑对象之间的交叉依赖。

业务逻辑对象和DAO对象合并后的组件关系如图8.3所示。

图8.3 合并DAO对象和业务逻辑对象

这种模型也导致了DAO方法和业务逻辑方法混合在一起，显得职责不够单一，软件分层结构不够清晰。此外，使业务逻辑对象之间交叉依赖，容易产生混乱，未能做到彻底的简化。

2．合并业务逻辑对象和Domain Object

在这种模型下，所有的业务逻辑都应该被放在Domain Object里面，而此时的业务逻辑层不再是传统的业务逻辑层，它仅仅封装了事务和少量逻辑，完全无需DAO对象的支持。而Domain Object依赖于DAO对象执行持久化操作，此处Domain Object和DAO对象形成双向依赖，这种设计在某些地方也被称为充血模式，但有时会带来相当大的危险。

在这种设计模式下，几乎不再需要业务逻辑层，而Domain Object则依赖DAO对象完成持久化操作，下面是在这种模式下的News类代码：

java 代码

public class News extends BaseObject
{
//此处省略了其他的属性。
//此处省略了属性对应的setter和getter方法
//增加新闻回复的业务逻辑方法
public NewsReview addNewsReview(String content)
{
//以默认构造器创建新闻回复实例
NewsReview review = new NewsReview();
//设置回复内容
review.setContent(content);
//设置回复的发布日期
review.setPostDate(new Date());
//设置回复的最后修改日期
review.setLastModifyDate(new Date());
//设置回复与消息的关联
review.setNews(this);
//直接调用newsReviewsDao完成消息回复的持久化。
newsReviewsDao.save(review);
return review;
}
//此处省略了重写的hashCode，equals等方法
}

从上面代码中可以看到，由于Domain Object必须使用DAO对象完成持久化，因此Domain Object必须接收IOC容器的注入，而Domain Object获取容器注入的DAO对象，通过DAO对象完成持久化操作。

合并业务逻辑对象和Domain Object后各组件的关系如图8.4所示。

这种模型的优点是：业务逻辑对象非常简单，只提供简单的事务操作，业务逻辑对象无须依赖于DAO对象。

但这种模型的缺点也是非常明显的：

— DAO对象和Domain Object形成了双向依赖，其复杂的双向依赖会导致很多潜在的问题。

— 业务逻辑层和Domain层的逻辑混淆不清，在实际项目中，极容易导致架构混乱。

— 由于使用业务逻辑对象提供事务封装特性，业务逻辑层必须对所有的Domain Object的逻辑提供相应的事务封装，因此业务逻辑对象必须重新定义Domain Object实现的业务逻辑，其工作相当烦琐。

图8.4 合并业务逻辑组件和Doamin Object

8.4.3 抛弃业务逻辑层

在Rich Domain Object模型的各种变化中，虽然努力简化业务逻辑对象，但业务逻辑对象依然存在，依然使用业务逻辑对象正面封装所有的业务请求。下面介绍更彻底的简化即，彻底放弃业务逻辑层。

抛弃业务逻辑层也有两种形式：

— Domain Object彻底取代业务逻辑对象。

— 由控制器直接调用DAO对象。

1．Domain Object完全取代业务逻辑对象

这种设计模式是充血模式更加激进的演化。由于在充血模式中业务逻辑对象的作用仅仅只提供事务封装，业务逻辑对象存在的必要性不是很大，因此考虑对Domain Object的业务逻辑方法增加事务管理，而Web层的控制器则直接依赖于Domain Object。

这种模型更加简化，使Domain Object与DAO对象形成双向依赖，而Web层的控制器直接调用Domain Object的业务逻辑方法。这种模型在有些地方也被称为胀血模式。

这种模型的优点是：分层少，代码实现简单。

但这种模型的缺点也很明显：

— 业务逻辑对象的所有业务逻辑都将在Domain Object中实现，势必引起Domain Object的混乱。

— Domain Object必须向Web层直接暴露，可能导致意想不到的问题。

这种模型与充血模式的缺点相同：Domain Object必须配置在Spring容器中，接受Spring容器的依赖注入。

在这种架构模型下，Domain Object相当不稳定。如果业务逻辑需要改变，Domain Object也需要发生改变，而DAO对象与Domain Object形成双向依赖，这将导致从底层的Domain Object和DAO对象的修改，使这种架构模式的分层完全失去意义。各层之间以强耦合方式组合在一起，各层对象互相依赖，牵一发而动全身，几乎是最差的一种策略。

2．控制器完成业务逻辑

在这种模型里，控制器直接调用DAO对象的CRUD方法，通过调用基本的CRUD方法，完成对应的业务逻辑方法。这种模型下，业务逻辑对象的功能由控制器完成。事务则推迟到控制器中完成，因此对控制器的execute方法增加事务控制即可。

对于基本的CRUD操作，控制器可直接调用DAO对象的方法，省略了业务逻辑对象的封装，这就是这种模型的最大优势。对于业务逻辑简单（当业务逻辑只是大量的CRUD操作时）的项目，使用这种模型也未尝不是一种好的选择。

但这种模型将导致控制变得臃肿，因为每个控制器除了包含原有的execute方法之外，还必须包含所需要的业务逻辑方法的实现。极大地省略了业务逻辑层的开发，避免了业务逻辑对象不得不大量封装基本的CRUD方法的弊端。

这种模型也有其缺点：

— 因为没有业务逻辑层，对于那些需要多个DAO参与的复杂业务逻辑，在控制器中必须重复实现，其效率低，也不利于软件重用。

— Web层的功能不再清晰，人为复杂化。Web层不仅负责实现控制器逻辑，还需要完成业务逻辑的实现，因此必须精确控制何时调用DAO方法控制持久化。

— 扩大了事务的影响范围。大部分情况下，只有业务逻辑方法需要增加事务控制，而execute方法无须增加事务控制。但如果execute方法直接调用了DAO对象的CRUD方法，则会导致这些方法不在事务环境下执行。为了让数据库访问都在事务环境下进行，因此不得不将事务范围扩大到整个execute方法。

本章小结

本章首先介绍了笔者在架构设计方面一些经验，从企业应用开发面临的困难讲起，并讲解了面对这些困难时应该采用何种应对策略。

其次介绍了常用的代理模式的使用，并深入介绍了由此衍生出来的Spring AOP框架。

最后重点介绍了贫血模型、Rich Domain Object模型、以及几种简化的模型，并分别分析了几种模型各自的优缺点。

分享到：

集成Spring与Hibernate | 常见SSH的架构设计策略（一）

2007-10-03 00:26
浏览 3281
评论(0)
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论