分层设计原则

分层设计原则
⼀，Service->DAO，只能在Service中注⼊DAO。

⼆，DAO只能操作表单数据，跨表操作放在Service中，Service尽量复⽤DAO，只有⼀张表产⽣的业务放⼊DAO中。

三，事务操作，放在⼀个DAO中。

四，如果有更⼤Service的之间的复杂调⽤，考虑在service上再加Facade层(Components组件)。

五，多考虑这部分代码放在哪⾥，多利⽤上下分层，增加代码可读性，提⾼代码复⽤率。

服务层处理业务逻辑，DAO封装Entity对象，Action作为Controller处理分发。

业务逻辑是最容易变化的地⽅，当业务改变时，只增加修改相应的代码即可。

真正享受分层带来的益处。

　
　J2EE分层设计是Java企业应⽤的最基本的设计思想。

从最常规的分层结构来说，系统层次从上到下依次为：
表现层：主要是客户端的展⽰。

服务层：直接为客户端提供的服务或功能。

也是系统所能对外提供的功能。

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

DAO层：数据访问对象，通过领域实体对象来操作数据库。

其中有些指导原则：
1、上层总是依赖其下层，依赖关系不跨层。

2、表现成除外，同⼀层之间⽅法不允许相互调⽤。

这是实际开发中⼀些开发者容易范的错误！如果真是同⼀层之间存在⽅法调⽤，需要注意，这些调⽤都是⼀些上层不可见⽅法，⽐如⼀些⼯具⽅法等。

3、⼀切从服务层出发，从系统需要提供的功能进⾏分析，确定Service接⼝中的⽅法。

⽽不是从数据库的表出发，创建DAO，再创Domain，然后Service，这实际上是对系统分层的误解。

4、系统最核⼼的设计就是将系统中的实体划分为领域模型。

在此基础上设计数据的DAO层，并将这些活动暴露给服务层，服务层的实现依赖于领域活动。

5、每个接⼝的职责范围明确有界。

　在我所做的系统中，常常看到⼀些糟糕的编码：系统设计从表开始，⼀个表对应⼀个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机。

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