关于DAO层的疑惑!!!平地一声雷

本文深入探讨了在S2SH开发环境中,DAO层应采用通用DAO还是模型特定DAO的设计策略。重点讨论了两者之间的优缺点,包括代码重用性、配置文件简洁性、灵活性以及耦合性等方面,旨在帮助开发者选择更适合项目需求的设计方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近一直在考虑一个问题,在S2SH开发中,DAO层到底应该怎么写?是一个通用DAO呢还是各个Model的DAO分开呢?

 

如果是各个MOdel的DAO分开写,这样会有很多重复代码,几乎每个DAO类里面都包含save,delete,update,load等一样标签的方法,和重用性相抵触,而且在application.xml中配置非常麻烦,每个DAO都得引用sessionFactory,这样配置文件也有很多冗余!

 

我个人认为,dao层只应提供数据持久化接口,和数据库,Service层均没有关系,如果持久化框架变了,比如不用Hibernate,而改用ibatIS,那么只需要将DAO里面的实现稍作改动,整个系统就可以流畅运行.所以,这就要求在Service层不要写HQL或者QBC,Service层专注调用DAO层接口为Action层提供服务,和DAO层无耦合.这样如果写一个通用DAO层的话,就会提高代码重用性,并且xml配置也很简洁,只要配置一个通用的dao就可以了,但是却使以牺牲灵活性为前提的,比如在Service层需要一个按属性查询的方法,那么在DAO层就要写where子句(where xxx=yyy),但是通用dao不可能知道xxx,怎么办呢?

 

如果通用DAO层接受Service层传来的HQL的话,那就会很容易写出一个灵活性高,重用性强的DAO通用层,但是这样又有了耦合性,持久化框架变化的话要改变的代码会很多,甚至可以说是牵一发而动全身.

 

所以,到底该怎么设计DAO层呢,思考良久,觉得,还是通用DAO比较合理一点,配置文件少,重用性高,这是大方向,然后如何写出一个和Service层无关的又有很高灵活性的DAO层,一直困扰我,各位大虾们,请说说你们的看法,你们有没有更好的方法?或者我的这个困惑是不是应该有的?该不该放弃低耦合?

 

 

最后,我希望大家不要用经验和我谈问题,经验都是看别人的代码学来的,真正思考过这个问题的才有发言权...

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值