DAO层当前应该存在,原因如下:
1,必尽还是关系数据库的时代,还有对于数据库访问不同数据库还是有存在差异,用DAO层实现来解决差异,除非ORM足够强大,根本不存在。
2,DAO分担业务层的逻辑(小逻辑),就如domain层实体里不光是setter,getter的原里一样。但这层逻辑业务仅针对DAO对应的domain层相关逻辑,否则建议到service层。
3,service层应该是主要业务逻辑,不关心应用逻是什么,service的逻辑接口应该永远不了,除非业务改变。个人认为我们的业务主逻辑图都在service层,再配罗dao的小逻辑,(千万不要把hibernate的HQL,或者 相关SQL在这里中写逻辑,初学者误区)。
4,DAO可以认为是大海,有无穷的资源,而service是大海上的船,是dao层上按需所取,船下的海域就是不同dao的小业务逻辑。dao与entity应该是强偶合性的,service以上是松偶合。
5,service不光要dao层,还是分布式,远程访问。就是银行转账的扩展。一般应用都是调用银行接口转账,还有相应的业务关联。转账可能不是一个事务的问题了(当然业务层的设计也可以解决,只是简单举例)
1,必尽还是关系数据库的时代,还有对于数据库访问不同数据库还是有存在差异,用DAO层实现来解决差异,除非ORM足够强大,根本不存在。
2,DAO分担业务层的逻辑(小逻辑),就如domain层实体里不光是setter,getter的原里一样。但这层逻辑业务仅针对DAO对应的domain层相关逻辑,否则建议到service层。
3,service层应该是主要业务逻辑,不关心应用逻是什么,service的逻辑接口应该永远不了,除非业务改变。个人认为我们的业务主逻辑图都在service层,再配罗dao的小逻辑,(千万不要把hibernate的HQL,或者 相关SQL在这里中写逻辑,初学者误区)。
4,DAO可以认为是大海,有无穷的资源,而service是大海上的船,是dao层上按需所取,船下的海域就是不同dao的小业务逻辑。dao与entity应该是强偶合性的,service以上是松偶合。
5,service不光要dao层,还是分布式,远程访问。就是银行转账的扩展。一般应用都是调用银行接口转账,还有相应的业务关联。转账可能不是一个事务的问题了(当然业务层的设计也可以解决,只是简单举例)