遇到一个设计上的问题，请问如何解决？

我只是不想在每个业务类都写类似于:

private TeacherManager teachermgr;
public setTeacherManager(..){..}

而是注入一个appImpl，然后通过app.get××××Manager()，取出任意一个我想要的业务类。

正解~
Manager, Service一类的东西,通常作为一个Facade或者integration script对外暴露服务接口的,应该互相没有依赖的关系。如果出现这种情况，就要回头考虑下设计是否有问题。

感觉是设计问题  为什么不把共同用到的东西网上拿
比如建个peopleService,studentService和teacherService都继承过来

或者说我们用组合
把peopleService注射到studentService和teacherService在他们之中通过
getPeopleService.xxx来调用呢?

我们碰到同楼主类似问题，一般解决方法如下：
1.避免出现这种设计，但是有时候为了这条规则，会使得编程非常繁琐，而且即使知道这条规则还是很容易犯错，虽然可以再改，但是浪费调试时间。

业务这样设计不一定是错的，比如互相调用findById方法，很正常的，但是在Spring里面一般这种用法就会导致循环依赖，所以不是业务设计的错，是要作些小改变来迁就IOC。

2.楼上已经有人提出了：把公共的东西提上来，建立一个Service或者Facade层，把循环依赖变成层与层之间的上下依赖。

3.第2点我只是说了个大概，我们的实际作法如下：
原则上架构如下，Service->Manager，只能在service中注入manager。
马上问题就出现了，到底什么代码放在manager中，什么代码放在service中。
进一步的原则：manager只能操作单表数据，跨表的操作放在service中，service中要尽量复用各个manager中提供的方法，避免在service中造轮子，只合一张表产生的业务就下压到manager中。

一开始大家会发现，manager中的代码比较多，感觉service中基本都是一行调用manager，不用着急的，真正的业务一定是跨表的操作居多，service很快也会膨胀的。

以上只是基本原则，不是绝对的，基本原则是让人快速判断的，以下是几个特殊的例子。

比如有一个加载图片的manager，是一个非常基础的小模块，但是属于某个大模块中的私有部分，因为这个manager非常孤立，也就是说不会需要注入其他的manager，这个时候可以考虑让其他的manager中注入这个图片manager。

还有规模稍大的模块之间的调用，对方已经是service暴露接口出来，如果对方模块也是比较孤立的，不会引用这边的service，也可以在service中注入service。

再有，如果是更大的模块之间的复杂调用，就可以考虑在service上再加一层Facade。

后面特殊例子举了这么多，还是请参考之前说的基本原则，应该能高效解决80%的场景，不用老是在那想这部分代码放哪里。
这些迁就未必是坏事，顺带的利用上下分层，能使程序可读性更好，manager这一层的复用程度能非常高。

如果通过Setter方式的依赖注入，Spring是支持Circular dependencies的，刚刚也做了简单的测试，在Spring2.5下启动和使用都没有问题

楼主能否贴一下详细的错误？

Service之间的依赖还是很普遍的，尤其成型产品出现需求变更的情况下

比如newsService.postComment负责处理新闻的评论操作，userService.addPoint负责用户积分的更新操作

现在网站需要搞活动，每个新闻评论赠与用户5点积分，这个时候newsService就要注入userService来实现了，当然这是一个简单的数据操作例子，可以注入userDao来实现，但是设想如果包含复杂的业务逻辑而不仅仅是数据操作的话（比如mail发送），这些都需要注入新的service对象而非简单的DAO对象。

搞这个app统一管理service干什么？spring就是做这个的。
而且你这个app里面包含了teacher自己， teacher又有app，肯定会死循环

spring不支持循环依赖的情况，真想进行循环依赖的话，貌似google guice支持的，没研究过

谢谢各位。看了becoder的帖子，我又改了一遍。解决了，虽然不完美，先凑活用吧。

一开始我全部用构造函数注入，难后改成属性注入，不知道什么原因，没有改干净，改来改去全糊涂。
现在确定，属性注入是支持的。

如果能全部用构造函数注入就好了，我是看了roller的源码才有这个想法，他是用的google guice。

用这种方法的好处就是，不用在业务层定义一大堆其他业务类的变量，只要一个就可以很方便的调用任何一个业务类。

这2天把代码优化了一下，把dao和manager（业务类）结合了，删掉了dao，分开写实在太累人。

在2.0.1下不行，我们以前碰到过。