谈谈Spring容器作为应用核心引擎的设计思考。

以前使用Spring一般出于几种考虑：
1）与Hibernate很好的集成
2）提供完善的事物管理框架
3）IoC实现，组装对象
4）AOP实现
至于扩展Aop实现，因为个人对AOP不是很了解，所以一直未扩展使用这个功能。
因为一个具体的业务逻辑需要使用到诸多的应用中已经设计好的基本组件，比如DAO，XMLConverter，Validator等等。
对于如此多的依赖，以及如此多的对象查找，生成/组装等等细节问题，一直以来是设计的重要部分，而如今，随着iOC.AOP容器的广泛出现，我们在可以通过插入一个容器来实现。
然而，稍微复杂一些的应用中，Spring容器往往很难一下子完美整合到应用中，比如说一个Observer模式，我已经设计好并已经编码完毕Observer和Observable的实现类，其中这两个类都关联着其他组件，对于这种具有关联关系的类，我们很容易也很自然的想到通过Spring容器组装，然而对于建立Observer实现和Observable实现间的关系，却是比较棘手的问题。
基于我对AOP比较粗浅的理解，不知道Spring容器能不能够实现这种对象间某种模式的关联，比如Observer，Listener。（其实也可以说基于非类定义的对象实例的模式关联，比如说一个对象在实例化后被add到另外一个对象实例的集合中，对象的规则基于第三方接口的契约，这种模型广泛应用于Listener，Observer模式）
我现在的应用，对于Spring容器的使用，一直是把它作为代理的角色使用，简单的属性组装可以让它来实现，而跟具体应用有关的组装逻辑，我还是用一个自己设计的Container类来实现，它可以更好的实现复杂的模式关联，比如Observer，Listener。为了更能说明问题，下面给出一个基本代码：

public interface BusinessI{
   public void doBusiness(Container container,Request request);;
}

public interface Container{
   public Validator getValidator(String name);;
  public DAO getDAO(String name);;
  public XMLConverter getXmlConverter();;
  //... more base component getter for Business Logic
  
} 

//有些人更愿意将Container这样设计,第二种写法
public interface Container{
  public ApplicationContext getContext();; //看到这个method，似乎Container是多余的，确实。我一直怀疑这点。
}

public interface Lifecycle {
   public void start();;
   public void stop();;
}

public class ContainerImpl implements Container ,Lifecycle{
    private ApplicationCotext ctx;
    public void start();{
      //... initialize the ApplicationContext 
       ctx=......;
       // 现在建立Observer和Observable之间的模式关系
    ((Observable);ctx.getBean("observable"););.addObserver(ctx.getBean("observer"););;
      //现在建立Listener 模式关系
     ((YourClass);ctx.getBean("aaa"););.addListener(ctx.getBean("youListener"););;
     //... 更多的特定逻辑
   
  }
       public void stop();{
       //... do logic before the stop
        //...
      }
    public DAO getDAO();{
      return (DAO);ctx.getBean("dao");; 
   }
   public Validator getValidator(String name);{
      return (Validator);ctx.getbean(name);; 
  }
   //......
}

其实作为Container所包含的逻辑来讲，我更愿意把它当作一个应用的Engine。无论怎么讲，我还是更期望Spring能够代替Container/Engine.让Spring更大限度的发挥它的作用，他的作用大到可以完全建立一个应用所有建立的所有对象层次关联的体系，甚至包括要容器保留的多个对象。
那么这样的应用就很简洁，只要在Spring容器中配置，组装应用所有涉及的关系，不仅包括哪些属性关联，这个关系的意义为具体应用的逻辑关系。
大家怎么看待我的思考，是不是胡思乱想呢？

Event handling in the ApplicationContext is provided through the ApplicationEvent class and
ApplicationListener interface. If a bean which implements the ApplicationListener interface is deployed
into the context, every time an ApplicationEvent gets published to the ApplicationContext, that bean will be
notified. Essentially, this is the standard Observer design pattern. Spring provides three standard events:

不知道是否是你要的功能

不是很喜欢！因为我原本与Spring无关的类现在要引入Spring专有的接口。
这是不大能让人接受的。

不是很赞成将Spring容器作为应用核心引擎的看法。

我对应用引擎的看法是：与应用逻辑密切相关，控制业务的核心流程。
而容器:只是为引擎及引擎中的Action、Listener、Handler提供他们所需要的Service.

例如我们在开发短信游戏中，专门会设计一个SmsGameEngine,它负责
1、短信接收、发送（自动分割短信、定时发送）
2、根据用户发送的指令、用户session状态进行区分，交给不同的SmsListener 处理，

public interface SmsListener {
      public void incoming(Message msg);;
}

所以SmsGameEngine本身也使用了一个List 保存各种SmsListener、
也使用了一个Hashtable 保存用户状态。
并不能因为它提供类似容器的功能保存各种SmsListener，就联想到使用
Spring 帮我们处理这一切跟业务关心很密切的逻辑。

我觉得我们更多考虑的应该是如何将应用引擎与Spring结合起来，如何让我们的开发更简单、规范、如何贯彻Ioc的开发方式。

Structs 我们可以看做一个Web应用的引擎，参看Spring是如何与Structs通过一个DelegatingActionProxy结合起来的，也许咱们有更多的启发。

使用委托类来联系Spring与Spring无关的类如何？

使用PublishEvent实现的observer(lister)显然需要商业对象是ApplicationContextAware的,而且接收方需要实现ApplicationLister接口

但是在spring.net中实现中，还有一种不用依赖的实现

public class RegexSource
  {
    public event CancelEventHandler Validating;
    public event EventHandler Validated;
  }
  
  public class CustomValidator
  {
    public void WhenValidating (object sender, CancelEventArgs e);
    {
      Console.WriteLine ("Got the 'Validating' event.");;
    }
    
    public void WhenValidated (object sender, EventArgs e);
    {
      Console.WriteLine ("Got the 'Validated' event.");;
    }
  }

<!-- the event source -->
  <object name="source"
    class="Examples.RegexSource, ExamplesLibrary"/>
  <!--
  an event listener that will respond to events raised from the 'source' object
  -->
  <object name="validator"
    class="Examples.CustomValidator, ExamplesLibrary">
    <listener event="Validating" method="WhenValidating">
      <ref local="source"/>
    </listener>
    <listener event="Validated" method="WhenValidated">
      <ref local="source"/>
    </listener>
  </object>

这种模式不确定在java中是否有

我觉得，如果仅需要spring的容器功能，是很容易分离出来的，但现在spring(java)的容器太强了，可以用脚本，xml,或编程来做，隔离它意义也不大，如果要使用applicationcontext的全部功能，像ApplicationLister,ResourceLoader,国际化等功能，要完全不使用spring的接口，事实上不可能的。

我觉的对于新项目，依赖spring并没有什么不好，毕竟不依赖spring就是依赖别的，要完全的不依赖也是过渡设计的一种，更何况依赖的仅是接口

至于要整合老项目，那可能要根据实际情况而言了