|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-12-07
现在我们项目中很规范的使用DAO 和 Service。 但是看看代码基本上DAO都是Service的代理， 重复的部分。DAO 完全跟Service是一样的。
其实直接用个AbstractService就行， 还省去了DAO层。 假如DAO仅仅上是Service的一个代理的话，考虑到数据库移植的话，其实DAO还是一样的。 |
| 返回顶楼 | |
|
发表时间：2006-12-12
无聊的问题
|
| 返回顶楼 | |
|
发表时间：2006-12-13
呵呵，讨论问题最好不要吵架。
|
| 返回顶楼 | |
|
发表时间：2006-12-13
dhj1 写道 如果为了省掉DAO,那还不如去玩纯JSP(或传统的JSP+BEAN)开发,这样更省代码,开发速度更快.
我认为DAO是不能省的,当你维护系统时就知道好处了. 如果是小东西,真的去用纯JSP(或传统的JSP+BEAN)更加实际. 大型一点的东西,还是什么都不要省最好. 就是就是。 |
| 返回顶楼 | |
|
发表时间：2006-12-13
这样的讨论此起彼伏.
|
| 返回顶楼 | |
|
发表时间：2006-12-13
数据库中的数据关系算不算业务逻辑，把hibernated对关系数据的读取是放在dao，还是service
|
| 返回顶楼 | |
|
发表时间：2006-12-13
这个话题讨论3天3夜也讨论不完，主要还是得看做什么项目，小项目，20个表的，随便搞一搞，想不用啥就不用啥，大项目，200个表，可就没有这么简单了，软件行业有很大一部是服务性质，肯定是要维护的，做产品更不用说了，能随便节省类的个数吗，节省了类的个数带来的是更紧的耦合（业务和持久的耦合），更糟糕的是在维护的时候成本会升高（更多人和时间），所以在做中大项目的时候一个好的清晰的架构是非常重要的。所以DAO还是非常有用的，千万不要认为hibernate已经实现了DAO，所以用了hibernate就不要DAO了，DAO的存在就是为了解耦，现在我们用hibernate，但是忽然说要换ibatis，这种情况很少，也不应该出现，但是因为政策原因出现了呢，我们必须换，但是用了DAO的时候，换起来就方便多了，直接把service和DAO放一起，我想程序员肯定会疯掉，所以DAO还是一个很有用的模式
|
| 返回顶楼 | |
|
发表时间：2006-12-14
分离存储逻辑和业务逻辑易于维护和扩充，重用率也高，整个软件的体系结构也很清晰。
|
| 返回顶楼 | |
|
发表时间：2006-12-31
我想如果用的话,还是分层的好,这是一个好的编程思想,也是一个好的编程习惯!我对自己的编程风格有一定的帮助!
|
| 返回顶楼 | |
