dao domain的理解

一，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 层：数据访问对象，通过领域实体对象来操作数据库。

　　其中有些指导原则：

　　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机。

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

　　希望以后大家在做项目的时候能注意点