|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-12-25
czx566 写道 service代码层面更多是过程代码，
因此不应该用IOC，直接用一个工厂类得了！ 而IOC应该用到领域模型里面! 真正的面向对象！ IOC的实现也是通过factory的！ |
| 返回顶楼 | |
|
发表时间：2009-01-15
我觉得第二种比较适合，就是不太清楚到底注入了dao没有，但是的确有些service是用不到dao的，第二种的话比较灵活
|
| 返回顶楼 | |
|
发表时间：2009-01-15
第一种，适合本系统数据库的数据访问。
第二中，适合把facade或util之类的通用业务对象注入到use case的业务对象中来。 小弟现在的项目中正好就遇到了这样的情况。 我的系统A，需要调用系统B和系统C的东西，每个系统都有自己独立的数据库。 现在有一个用例逻辑是这样的：先从系统B处读出一些数据，然后经过系统A的逻辑处理，再通过JMS的方式传递给C做处理。 我的系统A在做逻辑处理期间，会从数据库中读一些数据，所以就建立几个dao，注入到service中。 对系统B（EJB的方式），我就写了一个BFacade.java，每个EJB接口对应一个成员方法。 对系统C（监听JMS），我就写一个CQueueFacade.java，把插入JMS Queue的方法重载了几个，每个参数不同，就对应几种不同的入队方式。 再把这2个facade的service注入到A的service bean当中。 事务的配置方式是这样的：A service配置Require的，然后facade配置的support。这样就基本OK了。 大家觉得我这种配置方式怎么样，我觉得还比较科学，呵呵，系统大家批评指出。谢谢! |
| 返回顶楼 | |
|
发表时间：2009-01-15
正如你说的 如果出现
如果service1中有了业务逻辑可能到了bizService还要再写一遍 的情况 还是应该第二种 不过即便这样 我也不赞成第二种 因为 service层之间相互引用 很混乱 毕竟service之间有时没必要互相知晓的，如果service3有问题了 bizservice不也得改么 既然分层就是想在出现问题时可以只关注一个层面 个人愚见 |
| 返回顶楼 | |
|
发表时间：2009-01-15
偏向第二种，具体的那种合适，我也很迷惑，关注中。
|
| 返回顶楼 | |
|
发表时间：2009-01-16
最后修改：2009-01-16
学习中，发表下看法：
我们在实际的开发中两种情况都出现过，在最初开发初阶使用起来很方便，没有必要，将方法重写多遍。。。 现在开始项目维护，发现，在service中注入service开发是很方便，但是一旦牵连到业务方法的修改，那么就惨了。致使程序高度耦合， |
| 返回顶楼 | |
|
发表时间：2009-01-30
个人比较倾向第二种，简洁，节约代码！
|
| 返回顶楼 | |
|
发表时间：2009-02-02
我比较喜欢第二种，我觉得这样层次看的清楚，而且可以重用的
|
| 返回顶楼 | |
|
发表时间：2009-02-02
Spring是一个轻量级的架构，他说要达到的目的是为了更好的管理对象之间的关系，无论是复杂的应用还是简单的使用，都有举足轻重的作用！
|
| 返回顶楼 | |
|
发表时间：2009-02-03
czx566 写道 两种我都不同意
如果出现这种代码 <bean id = "service3" class = "com.test.Service3"> <property name="dao3" ref="dao3" /> <property name="dao4" ref="dao4" /> <property name="dao5" ref="dao5" /> <property name="dao6" ref="dao6" /> <property name="dao7" ref="dao7" /> <property name="dao8" ref="dao8" /> </bean> 要多难看就有多难看！ 个人认为 service层，不应该依赖IOC！ 人家问的问题都没看清楚就开始说。。。 |
| 返回顶楼 | |
