小样在胡说-2

    用了spring一段时间了，一直觉得是一个很好的东西，从未怀疑。但是由于最近的一次开发才突然发现，原来spring也有一些不尽人意的地方，至少我这样认为。


传统的spring开发模式下，我想大家开发应该都是这样的：
  首先定义一个interface dao
  interface UserDao{
User find(String name,String password);

}
再定义我的业务接口：
interface Login{
public boolean login(String name,String password);
}
接口定义完了，那么我就需要有我的实现，也许这样的两层我会分别交于两个不同的人去分别开发。

 
那么业务逻辑层的实现人员很有可能会按照Spring的IOC开发模式写下下面的代码：
public class LoginImpl implements Login{
private UserDao dao;

public setDao(UserDao dao){
this.dao = dao;
}

public boolean login(String name,String password){
     User user = dao.find(name，password);
     if(user!=null){
return true;
                     }else{
return false;
     }
}

}

这样貌似工作就完成了，可是如果我发现其实这个代码有下面的问题：
 
   1，过多的使用了 类变量，如果我上面的业务逻辑接口再多几个方法，那么很有可能，我的实现类先列出一排DAO
    那个时候就变成了
    public class LoginImpl implements Login{
private UserDao dao;
                  private ADAO a;
       private BDAO b;
    ......
   }
    而且这些变量的生命周期是与当前这个业务对象是一致的！
  
   2，违背OO设计的原则: 如果一个jsp程序调用的是将其强制转换为LoginImpl 类型，则jsp 程序是可以直接调用其setUser(null)这个方法而将dao设为空值或其它，而在这之后的调用，必然会对后面真正用此dao的方法产生破坏！


  3，如果我需要在这个UserDAO这个对象生成的时候，给这个对象加一层代理时，我必须将会在业务逻辑代码段中添加 加代理这样的代码，违背了Pojo设计的单纯性！


于是我觉得有必要更改spring的开发模式，于是出现了下面的代码

public class LoginImpl implements Login{

public boolean login(String name,String password){
     //此时依然也是利用spring的beanFactory去加载dao
     UserDao dao = (UserDao)BeanLoader("UserDao");
     User user = dao.find(name，password);
     if(user!=null){
return true;
                     }else{
return false;
     }
}
}
我发现上面的三个问题没有了，而spring本来所有优点基本都得到保留！我再回过头来看看这段代码，我发现我又回到了经典的工厂模式，不过决定这个工厂生产东西的不再是原来的java代码，而是我的bean.xml文件。

   基于此，我发现我用到的只是spring的类工厂，而对于spring实现的依赖注入的思想，完全是抛弃了的，灵活度却大大提高！
   那么我们为什么要依赖 Spring去注入到我们需要类中了？也许最终还是要回归到经典的23种设计模式

评论

7 楼 czx566 2008-12-30  

hrtc 写道

又回到了ejb时代，依赖注入不用反而去用依赖查找，这样做的话你的类就和工厂耦合了。

我不这么认为，你可以看看胡说-3，不过我觉得3写的不是很清楚，最近项目比较忙，如果有可能，我会再写胡说-4 来证明 依赖注入不是万金油，那里都必须的，而一定是有边界的！

6 楼 hrtc 2008-12-30  

又回到了ejb时代，依赖注入不用反而去用依赖查找，这样做的话你的类就和工厂耦合了。

5 楼 xijinn 2008-12-20  

Ioc带来的是很重要的思想，楼主如果这么用spring，我建议你还是别用了，对你没任何好处

4 楼 czx566 2008-12-17  

hypercube1024 写道

  " 2，违背OO设计的原则: 如果一个jsp程序调用的是将其强制转换为LoginImpl 类型，则jsp 程序是可以直接调用其setUser(null)这个方法而将dao设为空值或其它，而在这之后的调用，必然会对后面真正用此dao的方法产生破坏！ "老大，你到底用过Spring的IOC没有啊，IOC不一定要用set方法注入的，里面的private UserDAO userDAO;这个属性是可以直接注入的，不需要用set方法，具体的做法有很多，比如构造注入，或者直接用@Resource注释去注入都不需要用set方法，不会产生你所说的这种情况

你说的那些，我并没有提到，不是我没用过，而是我认为你列举的种种目的无非是要将
这个对象注入到另一个对象中，而我讨论的是这种目的是没有必要的~甚至认为是一种丑陋的设计。当然你实现这种目的可以有很多种方法~，但其中一种是违背面向对象的原则的！

3 楼 hypercube1024 2008-12-17  

  " 2，违背OO设计的原则: 如果一个jsp程序调用的是将其强制转换为LoginImpl 类型，则jsp 程序是可以直接调用其setUser(null)这个方法而将dao设为空值或其它，而在这之后的调用，必然会对后面真正用此dao的方法产生破坏！ "

老大，你到底用过Spring的IOC没有啊，IOC不一定要用set方法注入的，里面的
private UserDAO userDAO;这个属性是可以直接注入的，不需要用set方法，具体的做法有很多，比如构造注入，或者直接用@Resource注释去注入都不需要用set方法，不会产生你所说的这种情况

2 楼 czx566 2008-12-13  

zhaomingzm_23 写道

分析的很有道理,23种模式至今还未完全弄懂.惭愧中...

我现在又觉得spring的IOC还是有用的~不过不应该向现在这么用，这个涉及到领域模型的讨论~

1 楼 zhaomingzm_23 2008-12-11  

分析的很有道理,23种模式至今还未完全弄懂.惭愧中...