Question

java web 项目，DAO层应该如何设计？

公司的项目基本上一个domain一个dao接口和一个实现daoImpl,可是我想了半天没想出这有什么好，我的想法是：domain继承于EntityBase，然后用一个dao，通用增删改查方法和执行原生SQL语句的方法以及调用存储过程的方法等，参数用泛型<T extneds EntityBase>，复杂的业务全部定义在service中，在service中组合dao里面的方法，就不用给每一个domain定义dao实现了，求过来人指点下

Answer 1

DAO层一般有接口和该接口的实现类！ 接口用于规范实现类！ 实现类一般用于用于操作数据库！用于对数据库的增删改查。

DAO层的实现类中一般操作数据库操作的步骤很相似，可以抽取一个公共模版，封装成一个公共DAO类 ，进行数据库操作时，直接传递参数来调用公共类DAO类！

Answer 2

你说的没错，不一定是一个DAO层对应一个Entity，而是要通过业务来区分。比方说会员业务，其中包括了MemberEntity、MemberInfoEntity等这些实体，都是在一个业务里的。那么你的DAO层就需要编写关于这些实体的基础数据访问方法。然后在service实例化一个dao层的对象（可以new也可以用依赖管理容器），然后编写业务方法，不必用泛型。比如注册方法、登录方法来组合DAO层的基础数据访问方法。这些分层的用法，还是需要自己深入体会其含义。 纯手打，谢谢

Answer 3

大多的架构就是这么设计的，我公司项目架构也差不多这样的，我的理解就是更好的分层解耦合吧，就是把业务层和数据层分开，我们的架构是这样的，最外面业务层一个Controller,然后它回去调service层，然后它有个serviceimpl实现类，实现类里面要操作数据的时候就调用DAO层，然后DAO接口调DAOIMPL实现类，它里面就是hibernate或者是数据库的实现了，然后类包按照模块分的，每个包里都有个controller,service，serviceimpl,DAO,DAOIMPL。这大概就是体现了解耦合吧，是个标准的框架结构，这个完全可以按照项目的大小来订，比如可以DAO,DAOIMPL可以省略，看个人喜好了，只不过公司要规范化么所以框架也要有个样子不能想写哪里写哪里啊那样也不方便维护，毕竟代码不是一个人经手你乱分层的话后来的人就没法接了，我的理解就是这样你觉得呢？

Answer 4

就你想的那种啊！

追问

多谢支持，能不能详细说说。因为公司架构也是一位大神级的人物设计的。。。所以轻易不敢提出质疑

追答

是ssh项目？？