Where is the IoC? Where is the AOP?

很遗憾，我恰好很熟悉IoC和AOP，所以一旦我看到这样的代码：


  public JdbcDAO() {
    try {
      ServiceLocator sl = new ServiceLocator();
      dataSource = (DataSource) sl.getDataSource(JNDINames.DATASOURCE);


public abstract class Model implements Cloneable, Serializable {
  public boolean _modified = false;

  public boolean isCacheble() {
    return cacheble;
  }

我就禁不住要问了：你的IoC在哪里？为什么我满眼看到都是ServiceLocator却没有依赖注入？你的AOP在哪里？为什么我看到cache是用继承方式实现的？难道你是打算把UserTest extends Model称为“AOP”？

jdonframework本来还在开发中，谢谢你指出缺点。

> jdonframework本来还在开发中，谢谢你指出缺点。

那么就是说目前还没有IoC和AOP咯？那么http://www.jdon.com/jdonframework/这样说：“JdonFramework是Aop/Ico的实现，优异的缓存性能是其优点”。就是不实宣传咯？当然宣传策略是你自己的事，不过从我的经验，给你一个友善的建议：搞开源最好不要来不实宣传，很容易被唾弃的。

不好意思，我并不清楚jdonframework,多嘴了

唉，我只是一句话：想知道怎么用的，还是要好好耐心研究一下，我确实用了AOP和Ioc了..............
来信给我，我会告诉你的.

>> 唉，我只是一句话：想知道怎么用的，还是要好好耐心研究一下


dataSource = (DataSource) sl.getDataSource(JNDINames.DATASOURCE);
TestEJBLocal testEJB = (TestEJBLocal) WebAppUtil.getEJBService("testEJB",request);

别的我也不多说，我就一句话：这种遍布ServiceLocator的代码不能算IoC，除非你已经给IoC下了另一个定义。要证明一盘菜好吃，你或许需要吃完它；要证明它不好吃，尝一口就足够了。

>>我确实用了AOP和Ioc了

但我没有看到它们在哪里，却只看到了一些反模式、一些用了AOP和IoC不该出现的反模式，譬如说泛滥的工厂，譬如说对JNDI的绑定，譬如说为了获得infrastructure而继承一个具体类。用了还是没有，恐怕不是靠你说的，请举出代码示例。

>>来信给我，我会告诉你的

今天一个人问，明天又一个人问，你会很烦的。出于你方便考虑，建议一次性在这里公开澄清。

楼主逻辑有问题，举几个ServiceLocator就说明没用IoC？

楼主说的或许是对的，但你的口气让人讨厌，真的

楼主的话有什么讨厌的？
国内难道不是以华而不实的吹嘘为主吗？
当然，我相信banq，但是我更支持楼主。