81,116
社区成员
发帖
与我相关
我的任务
分享为什么习惯于把每个Entity对应一个Dao
看了不少开发实战，包括在Spring Data Jpa都是把每个Entity对应一个Dao
这样的好处在哪里？
做一些小项目的时候，也就两三个人。用SpringMVC+Hibernate做的时候
个Service都要添加一堆@AutoWired xxDao好像没有必要啊。
写个增删改是Object不需要区分
Hibernate Session的
persist(Object instance)
save(Object instance)
delete(Object instance)
都是不需要指明Entity类型的
查找也可以用泛型方法解决，比如这样
public <T> T findById(Class<T> clazzType,int id)
那么为什么还需要把每个Entity都对应一个Dao呢？
这样的好处在哪里？
做一些小项目的时候，也就两三个人。用SpringMVC+Hibernate做的时候
个Service都要添加一堆@AutoWired xxDao好像没有必要啊。
写个增删改是Object不需要区分
Hibernate Session的
persist(Object instance)
save(Object instance)
delete(Object instance)
都是不需要指明Entity类型的
查找也可以用泛型方法解决，比如这样
public <T> T findById(Class<T> clazzType,int id)
那么为什么还需要把每个Entity都对应一个Dao呢？
...全文
请发表友善的回复…
发表回复
JavaTree2017 2017-07-09
- 打赏
- 举报
主要是为了方便后期可读性，dao负责处理bean，而且dao可以具体写明操作，实体类就只设置属性即可
什么都不能 2017-07-08
- 打赏
- 举报
在你的心目中，系统就只是单个数据表的增删查改了？
那年桃花盛开时节 2017-07-07
- 打赏
- 举报
还没这个习惯，若一个业务需要多表关联查询的数据，那它应该放到哪个dao
HinanaiTenshi 2017-07-07
- 打赏
- 举报
笑项目完全没有必要把Dao和Entity对应，甚至完全可以不用持久层框架，这没有问题。
至于有一定规模的项目，可维护性和稳定性一般来说更重要。一个dao对应一个po，典型的专属服务，任何dao和po的错误不会导致异常扩散，影响整个系统。
公共po和dao是最可怕的，一个手贱的同事，一个切表的需求，一个特定表的优化，一组module的拆分，基本就是团队杀手的前奏。
另外有一定规模的项目通常对基础读写提供抽象类base-dao,其他所有dao继承这个dao做定制化开发，没有定制化语句就留一个空接口和方法就行，但分开用还是必须的。
lmkght 2017-07-07
- 打赏
- 举报
个人认为 基本的增删改是可以利用一个Object统一使用 不做管理 但项目中每个类所要实现的东西不同 所以区分出来便于修改查阅
darkread 2017-07-07
- 打赏
- 举报
类型安全用泛型方法是可以解决的。
如果按照我上面的设计，也可以实现代码重用。因为一个Entity一个Dao，那么必然Dao是非常薄的，厚的是Service。
显然，这个抽象的Service是很难产生的，总不能吧所有的Dao都作为属性给这个base service吧，这样和我用一个Dao有什么区别呢？
说到复用问题，现在都已经考写接口，直接代理实现了，已经简化到底了。复用的意义在哪里呢？
那年花 2017-07-03
- 打赏
- 举报
1.层次感明显，易读性比较强，这样可以让后面接手的人不用这么辛苦去读懂前面的人写的代码。
2.并不是每个实体类都需要dao的，有些实体类并不需要数据库的操作，所以不需要dao，只有需要进行数据库操作的才给他一个dao。
3.每个dao处理自己的实体类，这样不会混乱。
4.每个service对应自己的dao，除非必要是不会引用其他dao的，根本不会像你说的每个service10几个dao。
5.这是一种代码的设计模式，如果你想不出他好在哪里，那么请你先想出他不好在哪里。
Spinach007 2017-07-03
- 打赏
- 举报
类型安全、类型安全、类型安全
林二棍子 2017-07-03
- 打赏
- 举报
主要是为了可重用性和模块化设计考虑的。
这样如果要在其他项目中重用模块、dao和表结构，不需要重新编写代码。
Yee_123 2017-07-02
- 打赏
- 举报
现在已经被spring和hibernate整疯了，不过你说的新建一个service要复制粘贴的问题...你可以做一个baseService来管理所有的Dao，以后新建的service直接使用继承就可以。这是我刚下载的一个项目看到的方法。另外，对于一个entity对应一个dao的问题。我个人的理解，这个不是更符合OO设计？你把所有的dao的调用放一个service里本身就有问题吧。现在项目比较小这么做没什么问题，但是慢慢项目做大就会无法管理，会很乱，分开各自的service调用各自的dao，这样我觉得你就不会有一个dao对应一个entity的问题了。个人理解，我是菜鸟。
darkread 2017-07-02
- 打赏
- 举报
我相信是有好处的，好处在什么地方？
如果你一个Service要操作10个entity，那么是不是就要@AutoWired 10个Dao呢？
每次新写一个Service的就要把10个Dao复制粘贴一边，和OO不是很一致啊。而且也没有必要哦。
闪闪星空白白的光 2017-07-01
- 打赏
- 举报
反正我觉得每个entity对应一个dao挺好的，没有纠结过
闪闪星空白白的光 2017-07-01
- 打赏
- 举报
。。。。。。。那楼主你的Service就写一个啊？？？
darkread 2017-07-01
- 打赏
- 举报
个人觉得，如果一个entity一个Dao，那么Dao中的过程应该是很简单的，复杂的应该是在service中，那么公用的是service模块。
一些复杂的service曾要@Autowired N个Dao，那也是非常繁琐的一回事。我也知道既然很多人愿意这么写肯定有道理，那么道理在哪里，有不少好处，好处在哪里呢？
其实是来看看的 2017-06-30
- 打赏
- 举报
从思想上来说，分的细致有分的细致的有点。每个DAO 互不干扰。就是一堆低内聚，解耦合的这样的话。
项目中的删，增都是有很多条件的，并不是一个简单的save(entity)和delete(entity)。
一些查询的SQL 能append 很多很多行。太多模块共用一个DAO。上千行的代码看着确实挺烦的。
总之就是分开不费事，也有不少好处。那就分开吧
MikeDDT009 2017-06-30
- 打赏
- 举报
虽然还没学到你的进度，但是你都说了小项目可以不写，但是如果以后扩展起来很多内容以后，这样更方便使用。总的来说为什么习惯这样就是因为前人总结出来的经验，对吧，设计模式都是前人总结出来的怎么使用简便的一种经验，直接用吧，以后搞的多了再反过来看这样的好处就行了
