facade层,service 层,domain层,dao 层设计

转自http://fei-6666.iteye.com/blog/446247,记录下来html

一,Service->DAO,只能在Service中注入DAO。 

二,DAO只能操做但表数据,跨表操做放在Service中,Service尽可能复用DAO,只有一张表产生的业务放入DAO中。 

三,事务操做,放在一个DAO中。 

四,若是有更大Service的之间的复杂调用,考虑在service上再加Facade层(Components组件)。 

五,多考虑这部分代码放在哪里,多里利用上下分层,增长代码可读性,提升代码复用率。 

服务层处理业务逻辑,DAO封装Entity对象,Action做为Controller处理分发。 
业务逻辑是最容易变化的地方,当业务改变时,只增长修改相应的代码便可。真正享受分层带来的益处。 

文章出处:http://www.diybl.com/course/3_program/java/javaxl/2008620/126932.html 
  
 J2EE分层设计是Java企业应用的最基本的设计思想。 

  从最常规的分层结构来讲,系统层次从上到下依次为: 

  表现层:主要是客户端的展现。 

  服务层:直接为客户端提供的服务或功能。也是系统所能对外提供的功能。 

  领域层:系统内的领域活动。 

  DAO层:数据访问对象,经过领域实体对象来操做数据库。 

  其中有些指导原则: 

  一、上层老是依赖其下层,依赖关系不跨层。 

  二、表现成除外,同一层之间方法不容许相互调用。这是实际开发中一些开发者容易范的错误!若是真是同一层之间存在方法调用,须要注意,这些调用都是一些上层不可见方法,好比一些工具方法等。 

  三、一切从服务层出发,从系统须要提供的功能进行分析,肯定Service接口中的方法。而不是从数据库的表出发,建立DAO,再创Domain,而后Service,这其实是对系统分层的误解。 

  四、系统最核心的设计就是将系统中的实体划分为领域模型。在此基础上设计数据的DAO层,并将这些活动暴露给服务层,服务层的实现依赖于领域活动。 

  五、每一个接口的职责范围明确有界。 

  在我所作的系统中,经常看到一些糟糕的编码:系统设计从表开始,一个表对应一个DAO,一个DAO对应一个domain,一个Domain对应一个Service,实际上Service的接口和DAO的接口基本上彻底同样!致使Service的接口方法超多!到了表现层,前台程序员在写Action的时候,Action中反复的调用Service方法,代码不堪入目。 

  正确的设计应该是,一个领域活动会聚合对应一个或一组DAO,来完成一个领域活动。而一个服务可能包含两个领域活动,好比一个转帐的业务,对应两个领域活动。两个账户的金额分别发生变化,须要操做一组领域活动,而每一个活动须要操做不少表(调用多个DAO)。 事务的控制咱们能够放到Service层。 

  目前,愈来愈多的架构师喜欢领域模型驱动设计,针对系统的领域模型建模,而后上层直接是Service,Service下面就是领域活动层Activity,从而去掉了DAO层,这样作的优势是系统设计思路更清晰,目标更明确。能够避免上面所说的一个表对应一个DAO、Service的状况。 

  但缺点是当领域活动发生变化的时候,会引发领域活动层代码的变化。而且,当要更换持久化框架或者技术时候,领域活动要从新实现。 

  但综合考虑起来,这样带来的优势也不少,而实际上更换数据库和持久化框架的状况不多,所以这样的设计也是有其合理性一面的。这样作其实是将原来的DAO和Domain层合并为一个Activity.但上层的设计思路仍是一致的。 

  其实Service层的设计也很讲究,其中就是要控制Service的数量,从Service层往下,接口数量逐层增长。一般将一个模块的服务都集中到一个Service中来处理。 

  每层中的每一个接口都应该关注的是本身的那一块,而不是吃着碗里看着锅里,牛槽伸出个狗舌头,最典型的例子就是一个DAO中胡乱操道别的表。这种凌乱的实现只会置项目经理与死地。也会为软件的维护带来很大代价。 

  笔者曾遇到这样的团队,缺少对整个项目的总体设计,一个表一个DAO,对应一个Service,系统也不大,三四十张表,可是性能至关地下,常常down机。 

  最终发现,失败不是开源框架和数据库以及应用服务器和硬件配置的错,根源在于拙劣的设计致使。 

  但愿之后你们在作项目的时候能注意点 java

相关文章
相关标签/搜索