51,396
社区成员
发帖
与我相关
我的任务
分享DAO的设计问题 有点疑惑。。。。。麻烦大家帮忙接到
从网上查资料，好像很多朋友都用DAO模式封装对于数据库表的操作，不少人采用一个表一个dao的风格，最近项目涉及到很多的多表联合查询! 看了看一些文章，自己感觉是应该放到service里面，拼接sql语句然后传递给DAO去检索数据（这种方式需要灵活设计好参数的传递），又有不少朋友建议直接在dao里 写好语句就行了，有了新的需求就再写一个方法！感觉这样还是不太灵活。
不知道 大家都是如何设计的呢？ 如何应付这样的业务需求呢？ 麻烦大家帮忙分析下 谢谢
不知道 大家都是如何设计的呢？ 如何应付这样的业务需求呢？ 麻烦大家帮忙分析下 谢谢
...全文
请发表友善的回复…
发表回复
云想慕尘 2009-08-15
- 打赏
- 举报
咱不发表见解
fzd1129 2009-08-15
- 打赏
- 举报
个人建议还是一个表一个DAO的风格，多表联合查询的时候，把多表联合要查询的字段写成一个临时表，再开发这个表的DAO，这样做挺好用的
airelisa 2009-08-14
- 打赏
- 举报
你不会在数据库就建 好视图么?
dao直接查询视图不是更好
目前我做的项目虽然用了hib,同样也是这样处理的.
dao直接查询视图不是更好
目前我做的项目虽然用了hib,同样也是这样处理的.
guoqizhou 2009-07-29
- 打赏
- 举报
楼上说得好，人是活的嘛，要活用
kenshinlou 2009-07-29
- 打赏
- 举报
service不应该出现sql,这样做就失去分层的意义了,
要增加一个查询 要在action,service,dao层 加n多的代码，很烦？就这样（要不设计出一些通用的方法，以不变应万变）,分层必然会导致系统复杂度增加
要增加一个查询 要在action,service,dao层 加n多的代码，很烦？就这样（要不设计出一些通用的方法，以不变应万变）,分层必然会导致系统复杂度增加
forestandriver23 2009-07-26
- 打赏
- 举报
如果是固定方式的多表联合查询，可以构造一个view，然后针对这个view创建dao,这样不破坏分层结构。但是如果非固定方式的多表联合查询，可以在dao里增加专用方法。
个人认为不必为了dao而dao，分层另一方面的考虑是针对多表操作的时候，在业务层加入事务控制。如果你采用了dao方式，尽可能遵守就可以了。
个人认为不必为了dao而dao，分层另一方面的考虑是针对多表操作的时候，在业务层加入事务控制。如果你采用了dao方式，尽可能遵守就可以了。
laorer 2009-07-22
- 打赏
- 举报
如果是拼接的话, 那层次就不明显了,如果你不需要明显的分层, 拼接也无所谓,不过你要注意拼接时,可能会出现注入的现象
x114944880 2009-07-22
- 打赏
- 举报
大家都想写出又通用有方便的DAO！！！！那你就直接用Hibernate得了，用DAO就说明你项目小、开发周期短
；所以说，在DAO里可以直接写SQL语句，甚至用SQL来实现业务逻辑都可以的（一句话，你必须要快）
；所以说，在DAO里可以直接写SQL语句，甚至用SQL来实现业务逻辑都可以的（一句话，你必须要快）
南南北北 2009-07-22
- 打赏
- 举报
项目涉及到很多的多表联合查询!
你可以建立视图，然后对视图做个DAO.
我个人不推荐传sql进去，然后查询。
你可以建立视图，然后对视图做个DAO.
我个人不推荐传sql进去，然后查询。
qq774097676 2009-07-21
- 打赏
- 举报
感觉还是自己觉得哪种适合自己就用哪种吧 也不一定就要和别人的相同 不过现在一般是可以一个dao封装一个表 如果用一些框架也可以不用设计dao
bean 2009-07-21
- 打赏
- 举报
把多表联合要查询的字段设计成一个VO类，
sunsemon 2009-07-21
- 打赏
- 举报
个人建议还是一个表一个DAO的风格，多表联合查询的时候，把多表联合要查询的字段写成一个临时表，再开发这个表的DAO，这样觉得程序维护会好一点。仅供参考
