在Spring中DAO与Service关于依赖注入写法探讨

呵呵，似乎都把问题往固定的路线上去想。。。。。

其实，service本身也是可以分层的。可以根据业务的粒度来划分，比较细粒度的，通用的service是可以单独划分为一层，作为service这个大层中，位于底部的一层。

而那些上一层，粒度比较大的service，可以组合下一层，粒度比较细的service。

service本身划分的层次，可以通过不同的命名来区分。

以上是在大项目中实践过的，SUN设计的架构

也不太清楚倾向于哪 一种，个人第二种用的比较多，做过好几个系统


还是跟业务有关的   一般一个service 能搞定一个独立的功能


很多人说service 中绕service 


真当业务复杂到这种时候，可以在service上再建一层好了 去组织不同的service 保证多个service 的业务同步

因为如果service1中有了业务逻辑可能到了bizService还要再写一遍 


如果出现这种问题  应该是在类结构层次中没处理好

是不是要细分service，dao然后按需要重组？ 耐心看完大家的讨论，可还是不太明白，继续关注。

其实用Anonation一样要决定是sevice注入还是dao注入。如果是强业务逻辑的当然是service注入，如果简单逻辑可以使用dao注入

我一般在项目中都是对service进行事务代理，dao一般只是像DDL的简单封装。

service分为基础设施服务和业务服务两种，业务服务可以引用基础设施服务从而达到复用的目的！所以呀，关键是是要区分服务属于那种类型了，不能一概而论了

赞同。
往往有的粗业务逻辑比较复杂，它基于别的细粒度的业务逻辑。这个时候就不可避免的出现service调用service的情况。
好的做法是按照粒度将其再次分层。facade模式也是这个意思吧。

我一直有一个疑问，本来我们只关心业务的，可是现在的事务控制的复杂性使得我们在针对业务逻辑进行编码时不得不再去考虑事务。不然的话，很有可能造成死锁。

举一个例子：
ServiceA中的methodA操作a表，但是methodB又需要调用methodA（这是业务逻辑需要的），同时methodB在调用methodA之前还要操作a表。 如果事务配置不当，死锁就会频繁出现。

困惑中。。。

未必，service是将某逻辑方法的封装，这个被封装的业务，被另一个service调用，很常见的

这个在使用中确实比较经常用到。