讨论下ＳＳＨ开发中，service 层与dao层是如何规划的？

Question

此回复为自动发出,仅用于显示而已，并无任何其他特殊作用
楼主截止到2008-06-18 09:35:36的汇总数据：
发帖数:2
结贴数:0
结贴率: 0.00%
如何结贴请参考这里：http://topic.csdn.net/u/20080501/09/ef7ba1b3-6466-49f6-9d92-36fe6d471dd1.html

Answer 1

其实这就是Spring IOC的好处吧....繁琐..但很强大,你可以简洁Spring的配置...其实具体我也不太清楚,希望楼下能给出更好的建议,...

Answer 2

其实这就是Spring IOC的好处吧....繁琐..但很强大,你可以简洁Spring的配置...其实具体我也不太清楚,希望楼下能给出更好的建议,...

Answer 3

DAO层的职责是纯粹的数据操作， 如果是hibernate， 那就只需要类似getHibernateTemplate().save, update, delete, findyBy*这类的方法而service层是负责写业务逻辑的， 纯粹的业务逻辑， 其中的数据操作是通过注入的DAO实现的， 但是业务是在这层。
在这之前，你要分清楚什么是业务。

Answer 4

利用spring 的ioc 解偶 使业务逻辑与持久层松偶合

Answer 5

说明你的业务比较简单 复杂业务这个结构的优势就很明显了
service层的作用是对dao取得的数据做操作 更贴近于业务的实现
dao只是数据的增删改查

Answer 6

分层策略本身就是很好的方法！
在service中完成的功能觉不是简单的调用dao的接口来进行数据的增删改查。
你之所以感觉到service和dao的接口重复，很有可能是你的系统不够大，业务不够复杂。
对小型的应用来说，SSH 确实提高了开发成本和开发周期，但是却有利于扩展和维护。

Answer 7

可能是你的项目不够大的原因吧..我做项目分层和你的一模一样,刚开始只是增加
删除,修改的时候.也感觉有很多重复的地方,当时也想过这个问题,但随着接触的项目
逐渐增大,结合Spring的AOP..把类接口话..感觉还是挺好的

Answer 8

可能是你的项目不够大的原因吧..我做项目分层和你的一模一样,刚开始只是增加
删除,修改的时候.也感觉有很多重复的地方,当时也想过这个问题,但随着接触的项目
逐渐增大,结合Spring的AOP..把类接口话..感觉还是挺好的

Answer 9

Spring IOC的好处吧....繁琐..但很强大

Answer 10

domain 里本来就有充血和贫血2种 分场合了

Answer 11

分层并不一定是绝对的，具体的还是要根据项目实际情况来定，不是么？如果是理想状态的话，恐怕在你的service层上面还要再多加一层的。但是你觉得有必要吗？实际上，对于小项目来说，直接通过dao来进行操作也不是不可以，搞得太复杂，也没有必要。这是我的个人感觉。就好像po和dto一样，有的人直接就将po传到web层，有的还要加一个转换，由dto进行数据传递。显然后者实现更理想，但是你不觉得这样很麻烦吗。微软的。net号称有11层（还是多少层来着，反正层很多），但是实际能分出多少层，还是根据开发者自己情况来定了。要注意代码是死的，人是活的，不要死套框架，否则自己很可能也会陷入开发误区。另外，我们目前设计的一些领域对象，绝大多数都是贫血的。只是一个简单的javabean，不包含任何逻辑在里面。怎么设计才更符合oo的思想，你也可以参考下domain object方面的讨论。这个在javaeye上有很多。