问题描述
rt，最好举一些例子~~ 看了几遍理解不了~ 谢谢！spring 3.2 参考手册160页。内容如下：Glue code and the evil singletonIt is best to write most application code in a dependency-injection (DI) style, where that code is servedout of a Spring IoC container, has its own dependencies supplied by the container when it is created, andis completely unaware of the container. However, for the small glue layers of code that are sometimesneeded to tie other code together, you sometimes need a singleton (or quasi-singleton) style accessto a Spring IoC container. For example, third-party code may try to construct new objects directly(Class.forName() style), without the ability to get these objects out of a Spring IoC container. If theobject constructed by the third-party code is a small stub or proxy, which then uses a singleton styleaccess to a Spring IoC container to get a real object to delegate to, then inversion of control has still beenachieved for the majority of the code (the object coming out of the container). Thus most code is stillunaware of the container or how it is accessed, and remains decoupled from other code, with all ensuingbenefits. EJBs may also use this stub/proxy approach to delegate to a plain Java implementation object,retrieved from a Spring IoC container. While the Spring IoC container itself ideally does not have to bea singleton, it may be unrealistic in terms of memory usage or initialization times (when using beans inthe Spring IoC container such as a Hibernate SessionFactory) for each bean to use its own, non-singleton Spring IoC container. 问题补充：Glue code and the evil singletonIt is best to write most application code in a dependency-injection (DI) style, where that code is servedout of a Spring IoC container, has its own dependencies supplied by the container when it is created, andis completely unaware of the container. However, for the small glue layers of code that are sometimesneeded to tie other code together, you sometimes need a singleton (or quasi-singleton) style accessto a Spring IoC container. For example, third-party code may try to construct new objects directly(Class.forName() style), without the ability to get these objects out of a Spring IoC container. If theobject constructed by the third-party code is a small stub or proxy, which then uses a singleton styleaccess to a Spring IoC container to get a real object to delegate to, then inversion of control has still beenachieved for the majority of the code (the object coming out of the container). Thus most code is stillunaware of the container or how it is accessed, and remains decoupled from other code, with all ensuingbenefits. EJBs may also use this stub/proxy approach to delegate to a plain Java implementation object,retrieved from a Spring IoC container. While the Spring IoC container itself ideally does not have to bea singleton, it may be unrealistic in terms of memory usage or initialization times (when using beans inthe Spring IoC container such as a Hibernate SessionFactory) for each bean to use its own, non-singleton Spring IoC container.
解决方案
粘合代码和讨厌的单例（消除了编程实现单例）最好是大多数应用程序代码使用依赖项注入(DI)风格进行编写，一个IoC容器服务于该代码，由容器提供它自己的依赖，当它被创建时，它是完成不知道容器的。然而，对于小规模的粘合层代码，有时候需要关联其他代码，你有时候需要一个单例（或 类似单例）风格访问Spring IoC容器。例如，第三方代码可能设法直接构建新的对象（Class.forName() 风格），无法从一个Spring IoC容器中获取这些对象。如果第三方代码构建的对象是一个小的stub 或 proxy，然后使用单例风格访问Spring IoC容器来获取一个真实的对象并委托给它，那么控制反仍然实现了大部分代码（容器生产对象）。因此，大多数代码仍然是不知道容器的或它是如何被访问的，且仍然是和其他代码解耦的，拥有所有因此产生的好处。EJB也可以使用这种stub/proxy方法委托给一个从Spring IoC容器中取出的普通Java实现对象。虽然Spring IoC容器本身理想情况下不必是一个单例，非单例Spring IoC容器可能在内存使用期间是不切实际的或在初始化时间每一个Bean使用它（当使用的Bean在Spring IoC容器中，如Hibernate SessionFactory）。