DAO和service的解释

转自：http://blog.sina.com.cn/s/blog_4b1452dd0102wvox.html

我们都知道有了Hibernate后，单独对数据的POJO封装以及XML文件要耗损掉一个类（Orz意思是你需要精力写一个类）。然后，在大部分的服务中，我们又需要单独写一个Dao接口，并加个DaoImpl实现来操作数据库（好吧，再耗损2个类）。紧接着，我们发现其实Service层也要单独写一个类（再加1个）。

　　一共4个类外加1个xml……这不是作死么，5个文件。人家好端端地写PHP可能在一个php页面就完成全部功能了。显然，这么分工，得项目达到一定情况下，才有其适用性的。一个初步的设想是，由运维部分的数据库管理员（Database Administrator，简称DBA）提供设计好的表，并用相关Hibernate工具生成相应的POJO类与XML文档。（DBA主要负责业务数据库从设计、测试到部署交付的全生命周期管理）。

　　这样，对于开发人员来说，就可以尽情操作通过Hibernate获取的POJO类了。

　　对于单独分出Dao层与Service层的一些解释：

　　一个DAO单独对1个表进行操作。

　　一个Service可以操作几个DAO。

分层分析：那么这就意味着在几个大型数据库操作的时候，Service就能派的上用场。是不是这样分的？对于写入数据库的数据检查，交给Dao来。对于整个逻辑判断，交给Service来，例如在这张表找到了这个id字段，在那个表没找到，所以应该拒绝这项写入更新服务。

　　无论是哪种持久化存储， 数据访问对象（或称作为DAO，即Data Access Objects）通常都会提供对单一域对象的CRUD （创建、读取、更新、删除）操作、查询方法、排序和分页方法等。Spring Data则提供了基于这些层面的统一接口（CrudRepository，PagingAndSortingRepository）以及对持久化存储的实现。

 

Service和DAO的接口之有无：

　　接口是一种契约，它可以有多种实现。所以接口之有无取决于具体实现是否需要多样化。如果铁定一种DAO或一种Service只有一种实现，那么抽象出接口的意义不大（目前还无法想出Service的不同实现带来的好处）。然而一些大型应用或许需要DAO和Service的多种实现（比如帐户的DAO，可能需要一种Hibernate实现、一种CMP实现和一种JDO实现），为了向上一层隐藏具体实现类，需要采用接口。

　　隐藏具体实现类的创建过程，这有两种方法：一是实用工厂方法，代价是代码量大（每个DAO和Service一个工厂）。二是使用Spring的IoC，实现依赖注入，不需要写额外的代码，这也是引入Spring的理由之一