简而言之，我认为Spring是应用程序中的“粘合剂”。它用于集成不同的框架和您自己的代码。

Spring一开始是依赖注入，然后为几乎所有的东西添加了包装之王(JPA实现的包装等)。

说来话长……Spring的大多数部分更倾向于XML解决方案(XML脚本引擎…brrrr)，所以对于DI，我使用Guice

很好的库，但是随着依赖性的增长，例如Spring JDBC(可能是一个具有实名参数的Java JDBC解决方案)将从maven 4-5继承。

使用Spring MVC(“big Spring”的一部分)进行web开发…它是“基于请求的”框架，有“请求vs组件”的圣战…由你决定

过去，我从纯技术的角度考虑Spring框架。

根据一些团队工作和开发企业web应用程序的经验，我会说Spring通过解耦各个元素(bean)来实现更快的应用程序(web应用程序)开发。更快的发展使它如此受欢迎。Spring允许将构建(连接)应用程序的责任转移到Spring框架上。Spring框架的依赖注入负责将单个bean连接/连接到工作应用程序中。

这样，一旦定义了bean之间的接口，开发人员就可以更专注于单个组件(bean)的开发。

测试这样的应用程序很容易——主要的关注点是单个bean。它们可以很容易地解耦和模拟，因此单元测试是快速和有效的。

Spring框架定义了多个专门的bean，如@Controller (@Restcontroller)、@Repository、@Component来服务于web目的。Spring和Maven一起提供了一个对开发人员来说很直观的结构。 团队工作简单快捷，因为单独的元素是分开的，可以重复使用。

Spring是Enterprise JavaBeans (EJB)技术的一个很好的替代方案。它还具有web框架和web服务框架组件。

春天有三样东西。

Spring handles Dependency Injection and I recommend you read Martin Fowler's excellent introduction on dependency injection. The second thing Spring does is wrap excellent Java libraries in a very elegant way to use in your applications. For a good example see how Spring wraps Task Executors and Quartz Scheduler. Thirdly Spring provides a bunch of implementations of web stuff like REST, an MVC web framework and more. They figure since you are using Spring for the first two, maybe you can just use it for everything your web app needs.

The problem is that Spring DI is really well thought out, the wrappers around other things are really well thought out in that the other things thought everything out and Spring just nicely wraps it. The Spring implementations of MVC and REST and all the other stuff is not as well done (YMMV, IMHO) but there are exceptions (Spring Security is da bomb). So I tend to use Spring for DI, and its cool wrappers but prefer other stuff for Web (I like Tapestry a lot), REST (Jersey is really robust), etc.

基本上Spring是一个依赖注入框架，这种模式允许构建非常解耦的系统。

这个问题

例如，假设你需要列出系统的用户，并声明一个名为UserLister的接口:

public interface UserLister {
    List<User> getUsers();
}

也许一个实现访问一个数据库来获取所有的用户:

public class UserListerDB implements UserLister {
    public List<User> getUsers() {
        // DB access code here
    }
}

在你的视图中，你需要访问一个实例(只是一个例子，记住):

public class SomeView {
    private UserLister userLister;

    public void render() {
        List<User> users = userLister.getUsers();
        view.render(users);
    }
}

注意，上面的代码没有初始化变量userLister。我们该怎么办?如果我像这样显式地实例化对象:

UserLister userLister = new UserListerDB();

.．.我将视图与访问DB的类的实现结合在一起。如果我想从DB实现切换到另一个从逗号分隔的文件(记住，这是一个例子)获取用户列表的实现呢?在这种情况下，我将再次转到我的代码，并将上面的行更改为:

UserLister userLister = new UserListerCommaSeparatedFile();

这样的小程序没有问题，但是……在具有数百个视图和类似数量的业务类的程序中会发生什么?维护变成了噩梦!

Spring(依赖注入)方法

Spring所做的是使用XML文件或注释将类连接起来，这样所有的对象都由Spring实例化和初始化，并注入到正确的位置(servlet、Web框架、业务类、dao，等等，等等……)

回到Spring中的例子，我们只需要为userLister字段设置一个setter，并有一个像这样的XML文件:

<bean id="userLister" class="UserListerDB" />

<bean class="SomeView">
    <property name="userLister" ref="userLister" />
</bean>

或者更简单地用@Inject注释视图类中的字段:

@Inject
private UserLister userLister;

这样，当视图创建时，它将神奇地有一个UserLister准备工作。

List<User> users = userLister.getUsers();  // This will actually work
                                           // without adding any line of code

太棒了!不是吗?

如果您想使用UserLister接口的另一种实现呢?只需更改XML。 如果没有UserLister实现呢?编写UserLister的临时模拟实现，简化视图的开发。 如果我不想再使用Spring了怎么办?千万别用!您的应用程序没有与它耦合。控制反转:“应用程序控制框架，而不是框架控制应用程序”。

还有一些其他的依赖注入选项，在我看来，除了简单、优雅和稳定之外，Spring之所以如此有名，是因为SpringSource的人编写了许多pojo，这些pojo有助于将Spring与许多其他通用框架集成在一起，而不会对应用程序造成干扰。此外，Spring还有几个不错的子项目，比如Spring MVC、Spring WebFlow、Spring Security，还有一长串等等。

无论如何，我鼓励你阅读Martin Fowler关于依赖注入和控制反转的文章，因为他在这方面做得比我好。在了解了基本知识之后，看看Spring Documentation，在我看来，它是有史以来最好的Spring书籍。