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

Manager是Manager.spring的事务肯定在Manager一层做了. Manager在调用Manager.事务处理比较麻烦.
而且.如果使用了OpenSessionInView的话.在manager当中先find一个对象.这个时候session是readonly.在update也会有问题.manager那在加入一曾dao

抛开spring,我觉得lz的设计思路就是有问题的,看看设计模式吧.

lz写的我没看太明白,但应该可以用装饰器解决的,根本没有必要这样吧,这是思路上的问题,用生活逻辑来解决计算机逻辑了.

new 怎么会内存泄漏?这是什么逻辑? 妄图用工具解决基础语法问题,这好像不太合适吧.

还是绝对不要做Service之间的倚赖最好。
简单的操作，可以在service中注入多个dao
复杂的业务逻辑只要把这个操作提升到facade中去。

原因：
1.方便测试
2.业务逻辑0耦合

这个也试过，好像在2.0.1下还是会碰到问题的。

老实说，我忘了是2.0.1还是1.2了，很早以前遇到的，我们用了个约定只能上下依赖（只能在service中注入manager，除了10%的例外）解决这个问题后就再也没测过。

退回来说，即使spring支持语义上的循环以来，但是实际跑起来还是有可能产生应用上的循环依赖。
以前不用Spring的时候，刚学Java的时候也经常碰到循环依赖的困惑，所以结构上采用上下分层依赖和复用基本能解决90%的情况，基本能排除团队中由于不仔细考虑逻辑上确实互相依赖，因为上下分层能让他主动的把代码上下分开，不用的service互相调用（复用）对应的下层manager。

进一步的举例，未必两个manager一定要有两个service的，有些时候就完全可以两个manager一个service。
为什么我要举这个例子呢，这个例子最终表现形式的不就是传统的解决循环依赖的方法的一种么？

如果这样，就没必要用Spring了，用Spring就是为了解决每次new的时候，自己注入一堆参数。
而且测试不方便。

做一个项目，做完就扔给客户，不再由你开扩展，不再由你来维护，用这个挺好的；

好像c#里面这点叫循环依赖吧?

我觉得还是Service Layer调用manager layer层可以解决此问题，看起来也舒服。
在容器里配置以autoware完全可以解决。
搞不懂为什么还要写的那么复杂。
以service--->manager的架构也令人感觉比较清晰
<bean id="userManager" class="com.asflex.manager.UserManagerImpl" autowire="byType"/>

<bean id="userService" class="com.asflex.service.UserServiceImpl" autowire="byType"/>

public interface UserManager {
      public User createUser(User u);
}
public class UserManagerImpl() extends HibernateDaoSuport implements UserManager {
      public User createUser(User u) {
          return (User) getHibernateTemplate().save(u);
      }
}

public interface UserService {
      public User createUser(User u);
}
public class UserServiceImpl{
      private UserManager userManager;
      public void setUserManager(UserManager userManager) {
           this.userManager = userManager;
      }
      public User createUser(User u) {
          return userManager.create(u);
      }
}


大家觉得这样是不是更好呢：）