vlambda博客
学习文章列表

还有许多其他用于 Java 开发的 框架，它们通过强制您扩展或实现它们现有的类或接口之一来锁定您； Struts、Tapestry 和早期版本的 EJB 都有这种方法。这些框架的编程模型基于侵入模型。这使您的代码更难找到系统中的错误，有时它会使您的代码难以理解。但是，如果您使用 Spring Framework，则不需要实现或扩展其现有的类和接口，因此这只是基于 POJO 的实现，遵循非侵入式编程模型。它使您的代码更容易找到系统中的错误，并使代码易于理解。

Spring 允许您使用非常简单的非 Spring 类进行编程，这意味着不需要实现特定于 Spring 的类或接口，因此基于 Spring 的应用程序中的所有类都只是 POJO。这意味着您可以在不依赖 Spring 库的情况下编译和运行这些文件；您甚至无法识别 Spring Framework 正在使用这些类。在基于 Java 的配置中，您将使用 Spring 注解，这是基于 Spring 的应用程序的最坏情况。

让我们借助以下示例来看看这个：

    package com.packt.chapter1.spring; 
    public class HelloWorld { 
      public String hello() { 
        return "Hello World"; 
      } 
    } 

前面的类是一个简单的 POJO 类，没有与框架相关的特殊指示或实现，使其成为 Spring 组件。因此，此类在 Spring 应用程序中的功能与在非 Spring 应用程序中的功能相同。这就是 Spring 的非侵入式编程模型的美妙之处。 Spring 支持 POJO 的另一种方式是使用 DI 模式与其他 POJO 协作。让我们看看 DI 如何帮助解耦组件。

依赖注入这个术语并不新鲜——它被 PicoContainer 使用。依赖注入是一种设计模式，它促进了 Spring 组件之间的松散耦合——即不同的协作 POJO 之间。因此，通过将 DI 应用于您的复杂编程，您的代码将变得更简单、更易于理解和更易于测试。

在您的应用程序中，许多对象根据您的要求为特定功能协同工作。对象之间的这种协作实际上称为依赖注入。在工作组件之间注入依赖关系有助于您对应用程序中的每个组件进行单元测试，而无需紧密耦合。

在一个工作的应用程序中，最终用户想要的是看到输出。为了创建输出，应用程序中的一些对象一起工作，有时是耦合的。所以在编写这些复杂的应用类时，要考虑这些类的可重用性，并使这些类尽可能独立。这是编码的最佳实践，将帮助您独立地对这些类进行单元测试。

DI 如何工作并使开发和测试变得容易

让我们看看您的应用程序中的 DI 模式 implementation。它使事情易于理解、松散耦合并且可在整个应用程序中测试。假设我们有一个简单的应用程序（比您可能在大学课程中制作的 Hello World 示例更复杂）。每个班级都在共同努力执行一些业务任务并帮助建立业务需求和期望。这意味着应用程序中的每个类都对业务任务以及其他协作对象（其依赖项）负责衡量。让我们看看下面的图像。对象之间的这种依赖关系会在依赖对象之间产生复杂性和紧密耦合：

TransferService 组件传统上依赖于另外两个组件：TransferRepository 和 AccountRepository

一个典型的应用系统由几个部分组成，这些部分协同工作以执行一个用例。例如，考虑 TransferService 类，如下所示。

TransferService 使用直接实例化：

    package com.packt.chapter1.bankapp.transfer; 
    public class TransferService { 
      private AccountRepository accountRepository; 
      public TransferService () { 
        this.accountRepository = new AccountRepository(); 
      } 
      public void transferMoney(Account a, Account b) { 
        accountRepository.transfer(a, b); 
      } 
    } 

Copy

TransferService 对象需要一个 AccountRepository 对象才能从帐户 a 进行资金转账记入 b。因此，它直接创建 AccountRepository 对象的实例并使用它。但是直接实例化会增加耦合并分散应用程序中的对象创建代码，从而难以维护并且难以为 TransferService 编写单元测试，因为在这种情况下，每当您想使用 assert TransferService 类的 transferMoney() 方法code> 进行单元测试，则该测试不太可能调用 AccountRepository 类的 transfer() 方法。但是开发者不知道 AccountRepository 对 TransferService 类的依赖；至少，开发人员无法使用单元测试来测试 TransferService 类的 transferMoney() 方法。

在企业应用程序中，耦合是非常危险的，它会将您推到将来您将无法对应用程序进行任何增强的情况，在这种应用程序中任何进一步的更改都会产生很多错误，并且在哪里修复这些错误可能会产生新的错误。紧密耦合的组件是这些应用程序中出现主要问题的原因之一。不必要的紧耦合代码使您的应用程序无法维护，并且随着时间的推移，它的代码将不会被重用，因为其他开发人员无法理解它。但有时企业应用程序需要一定程度的耦合，因为在现实世界中不可能实现完全解耦的组件。应用程序中的每个组件对角色和业务需求都有一定的责任，以至于应用程序中的所有组件都必须了解其他组件的责任。这意味着有时耦合是必要的，但我们必须非常小心地管理所需组件之间的耦合。

    package com.packt.chapter1.bankapp.transfer; 
    public class TransferService { 
      private AccountRepository accountRepository; 
      public TransferService() { 
        this.accountRepository = 
          AccountRepositoryFactory.getInstance("jdbc"); 
      } 
      public void transferMoney(Account a, Account b) { 
        accountRepository.transfer(a, b); 
      } 
    } 

    public interface AccountRepository{ 
      void transfer(); 
      //other methods 
    } 

    public class JdbcAccountRepositry implements AccountRepositry{ 
      //...implementation of methods defined in AccountRepositry 
      // ...implementation of other methods 
    } 

根据 DI 模式，依赖的 objects 在某些工厂或第三方创建对象时被赋予它们的依赖关系。这个工厂协调系统中的每个对象，使得每个依赖对象都不希望创建它们的依赖关系。这意味着我们必须专注于定义依赖关系，而不是解决企业应用程序中协作对象的依赖关系。让我们看看下面的图像。您将了解到依赖项被注入到需要它们的对象中：

应用程序中不同协作组件之间的依赖注入

为了说明这一点，让我们看看下一节中的 TransferService -- TransferService 与 AccountRepository 和 TransferRepository。在这里，TransferService 能够通过 TransferRepository 的任何类型实现来转账，也就是说，我们可以使用 JdbcTransferRepository 或 JpaTransferRepository，具体取决于部署环境。

TransferServiceImpl 足够灵活，可以处理它给出的任何 TransferRepository：

    package com.packt.chapter1.bankapp; 
    public class TransferServiceImpl implements TransferService { 
      private TransferRepository transferRepository; 
      private AccountRepository  accountRepository; 
      public TransferServiceImpl(TransferRepository transferRepository,
       AccountRepository  accountRepository) { 
         this.transferRepository =
          transferRepository;//TransferRepository is injected 
         this.accountRepository  = accountRepository; 
         //AccountRepository is injected 
       } 
       public void transferMoney(Long a, Long b, Amount amount) { 
         Account accountA = accountRepository.findByAccountId(a); 
         Account accountB = accountRepository.findByAccountId(b); 
         transferRepository.transfer(accountA, accountB, amount); 
       } 
    } 

在这里您可以看到 TransferServiceImpl 没有创建自己的存储库实现。相反，我们在构造时将存储库的实现作为构造函数参数给出。这是一种称为 构造函数注入 的 DI。在这里，我们将存储库接口类型作为构造函数的参数传递。现在 TransferServiceImpl 可以使用存储库的任何实现，无论是 JDBC、JPA 还是模拟对象。关键是 TransferServiceImpl 没有耦合到任何特定的存储库实现。使用哪种存储库将金额从一个帐户转移到另一个帐户并不重要，只要它实现了存储库接口即可。如果您使用 Spring Framework 的 DI 模式，松散耦合是主要优势之一。 DI 模式总是促进 P2I，因此每个对象通过其关联接口而不是关联实现来了解其依赖关系，因此可以轻松地将依赖关系与该接口的另一个实现交换，而不是更改为其依赖的类实现。

Spring 为从它的各个部分组装这样一个应用程序系统提供了支持：

通过创建应用程序部件或组件之间的关联来组装应用程序系统的方法称为wiring。在 Spring 中，有 许多 方法将协作组件连接在一起以构成应用程序系统。例如，我们可以使用 XML 配置文件或 Java 配置文件。

现在让我们看看如何将TransferRepository和AccountRepository的依赖注入到一个TransferService 与弹簧：

    <?xml version="1.0" encoding="UTF-8"?> 
    <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> 
    <bean id="transferService" class="com.packt.chapter1.bankapp.service.TransferServiceImpl"> 
         <constructor-arg ref="accountRepository"/> 
         <constructor-arg ref="transferRepository"/> 
    </bean> 
    <bean id="accountRepository" class="com. packt.chapter1.bankapp.repository.JdbcAccountRepository"/> 
    <bean id="transferRepository" class="com. packt.chapter1.bankapp.repository.JdbcTransferRepository"/>     
    
    </beans> 

这里，TransferServiceImpl、JdbcAccountRepository和JdbcTransferRepository在Spring中被声明为bean .在 TransferServiceImpl bean 的情况下，它被构造，传递对 AccountRepository 和 的引用TransferRepository bean 作为构造函数参数。您可能想知道 Spring 还允许您使用 Java 表达相同的配置。

Spring 提供基于 Java 的配置作为 XML 的替代方案：

    package com.packt.chapter1.bankapp.config; 
 
    import org.springframework.context.annotation.Bean; 
    import org.springframework.context.annotation.Configuration; 
 
    import com.packt.chapter1.bankapp.repository.AccountRepository; 
    import com.packt.chapter1.bankapp.repository.TransferRepository; 
    import 
     com.packt.chapter1.bankapp.repository.jdbc.JdbcAccountRepository; 
    import 
     com.packt.chapter1.bankapp.repository.jdbc.JdbcTransferRepository; 
    import com.packt.chapter1.bankapp.service.TransferService; 
    import com.packt.chapter1.bankapp.service.TransferServiceImpl; 
 
    @Configuration 
    public class AppConfig { 
    
     @Bean 
     public TransferService transferService(){ 
       return new TransferServiceImpl(accountRepository(),
       transferRepository()); 
     } 
     @Bean 
     public AccountRepository accountRepository() { 
       return new JdbcAccountRepository(); 
     } 
     @Bean 
     public TransferRepository transferRepository() { 
       return new JdbcTransferRepository(); 
     } 
    } 

无论您使用的是基于 XML 的配置还是基于 Java 的配置，依赖注入模式的好处都是相同的：

虽然 TransferService 依赖于一个 AccountRepository 和 TransferRepository，但它并不关心关于应用程序中使用的 AccountRepository 和 TransferRepository 的实现类型（JDBC 或 JPA）。只有 Spring 通过其配置（基于 XML 或 Java）知道所有组件如何组合在一起并使用 DI 模式使用它们所需的依赖项进行实例化。 DI 可以在不更改依赖类的情况下更改这些依赖项——也就是说，我们可以使用 JDBC 实现或 JPA 实现而不更改 AccountService 的实现。

在 Spring 应用程序中，应用程序上下文的实现（Spring 为基于 Java 的实现提供 AnnotationConfigApplicationContext，为基于 XML 的实现提供 ClassPathXmlApplicationContext ) 加载 bean 定义并将它们连接到 Spring 容器中。 Spring 中的应用程序上下文在启动时为应用程序创建并连接 Spring bean。使用基于 Java 的配置查看 Spring 应用程序上下文的实现——它加载 Spring 配置文件（Java 的 AppConfig.java 和 Sprig .xml for XML）位于应用程序的类路径中。在以下代码中，TransferMain 类的 main() 方法使用了 AnnotationConfigApplicationContext< /code> 类加载配置类 AppConfig.java 并获取 AccountService 类的对象。

Spring 提供基于 Java 的配置作为 XML 的替代方案：

    package com.packt.chapter1.bankapp; 
 
    import org.springframework.context.ConfigurableApplicationContext; 
    import 
     org.springframework.context.annotation
     .AnnotationConfigApplicationContext; 
 
    import com.packt.chapter1.bankapp.config.AppConfig; 
    import com.packt.chapter1.bankapp.model.Amount; 
    import com.packt.chapter1.bankapp.service.TransferService; 
 
    public class TransferMain { 
 
      public static void main(String[] args) { 
        //Load Spring context 
        ConfigurableApplicationContext applicationContext = 
          new AnnotationConfigApplicationContext(AppConfig.class); 
         //Get TransferService bean 
         TransferService transferService = 
          applicationContext.getBean(TransferService.class); 
           //Use transfer method 
         transferService.transferAmmount(100l, 200l,
          new Amount(2000.0)); 
         applicationContext.close(); 
      } 
 
    }    

这里我们快速介绍一下依赖注入模式。在本书的后续章节中，您将了解更多关于 DI 模式的知识。现在让我们看一下使用 Spring 的声明式编程模型通过切面和代理模式来简化 Java 开发的另一种方法。

在 Spring 应用程序中，DI 模式为我们提供了协作软件组件之间的松散耦合，但 Spring 中的 Aspect-Oriented Programming (Spring AOP) 使您能够捕获在整个应用程序中重复的常见功能。所以我们可以说 Spring AOP 提倡松散耦合并允许横切关注点（如下所列）以最优雅的方式分离。它允许通过声明透明地应用这些服务。使用 Spring AOP，可以编写 自定义方面并以声明方式配置它们。

应用程序中 许多 位置所需的通用功能是：

此处列出的组件不是您的核心应用程序的一部分，但这些组件具有一些额外的职责，通常称为横切关注点，因为它们倾向于跨越系统中的多个组件，超出其核心职责。如果你把这些组件和你的核心功能放在一起，从而在没有模块化的情况下实现横切关注点，它将有两个主要问题：

下图说明了这种复杂性。业务对象与横切关注点过于密切相关。每个对象不仅知道它正在被记录、保护并参与事务上下文，而且每个对象还负责执行仅分配给它的那些服务：

横切关注点，例如日志记录、安全性和事务处理，通常分散在模块中，而这些任务不是它们的主要关注点

Spring AOP 实现了横切关注点的模块化，以避免缠结和分散。您可以将这些模块化的关注点以声明的方式应用到应用程序的核心业务组件上，而不会影响上述组件。这些方面确保 POJO 保持清晰。 Spring AOP 通过使用代理设计模式使这个魔法成为可能。我们将在本书后面的章节中更多地讨论代理设计模式。

Spring AOP 的工作原理

以下几点描述了 Spring AOP 的工作：

• Implement your mainline application logic: Focusing on the core problem means that, when you are writing the application business logic, you don't need to worry about adding additional functionalities, such as logging, security, and transaction, between the business codes-Spring AOP takes care of it.
• Write aspects to implement your cross-cutting concerns: Spring provides many aspects out of the box, which means you can write additional functionalities in the form of the aspect as independent units in Spring AOP. These aspects have additional responsibilities as cross-cutting concerns beyond the application logic codes.
• Weave the aspects into your application: Adding the cross-cutting behaviors to the right places, that is, after writing the aspects for additional responsibilities, you could declaratively inject them into the right places in the application logic codes.

我们来看一个 Spring 中 AOP 的图解：

基于 AOP 的系统演化——这让应用程序组件专注于其特定的业务功能

在上图中，Spring AOP 将横切关注点（例如安全、事务和日志记录）从业务模块中分离出来，即 BankService、CustomerService 和 ReportingService。这些横切关注点在应用程序运行时应用于业务模块的预定义点（上图中的条纹）。

假设您要使用 TransferService 的 transferAmmount() 方法之前和之后记录消息class="literal">LoggingAspect。以下清单显示了您可能使用的 LoggingAspect 类。

LoggingAspect 调用用于为 TransferService 记录系统：

    package com.packt.chapter1.bankapp.aspect; 
 
    import org.aspectj.lang.annotation.After; 
    import org.aspectj.lang.annotation.Aspect; 
    import org.aspectj.lang.annotation.Before; 
 
    @Aspect 
    public class LoggingAspect { 
    
     @Before("execution(* *.transferAmount(..))") 
     public void logBeforeTransfer(){ 
       System.out.println("####LoggingAspect.logBeforeTransfer() 
       method called before transfer amount####"); 
     } 
    
     @After("execution(* *.transferAmount(..))") 
     public void logAfterTransfer(){ 
       System.out.println("####LoggingAspect.logAfterTransfer() method
       called after transfer amount####"); 
     } 
    } 

Copy

要将 LoggingAspect 转换为切面 bean，您只需在 Spring 配置文件中将其声明为切面 bean。此外，要使其成为一个方面，您必须将 @Aspect 注释添加到此类。这是更新后的 AppConfig.java 文件，修改后将 LoggingAspect 声明为方面。

将 LoggingAspect 声明为切面并启用 Spring AOP 的 Apsect 代理功能：

    package com.packt.chapter1.bankapp.config; 
 
    import org.springframework.context.annotation.Bean; 
    import org.springframework.context.annotation.Configuration; 
    import
     org.springframework.context.annotation.EnableAspectJAutoProxy; 
 
    import com.packt.chapter1.bankapp.aspect.LoggingAspect; 
    import com.packt.chapter1.bankapp.repository.AccountRepository; 
    import com.packt.chapter1.bankapp.repository.TransferRepository; 
    import
     com.packt.chapter1.bankapp.repository.jdbc.JdbcAccountRepository; 
    import
     com.packt.chapter1.bankapp.repository.jdbc.JdbcTransferRepository; 
    import com.packt.chapter1.bankapp.service.TransferService; 
    import com.packt.chapter1.bankapp.service.TransferServiceImpl; 
 
    @Configuration 
    @EnableAspectJAutoProxy 
    public class AppConfig { 
    
      @Bean 
      public TransferService transferService(){ 
        return new TransferServiceImpl(accountRepository(),
        transferRepository()); 
      } 
      @Bean 
      public AccountRepository accountRepository() { 
        return new JdbcAccountRepository(); 
      } 
      @Bean 
      public TransferRepository transferRepository() { 
        return new JdbcTransferRepository(); 
      } 
      @Bean 
      public LoggingAspect loggingAspect() { 
        return new LoggingAspect(); 
      } 
    } 

Copy

在这里，我们使用 Spring 的基于 Java 的 AOP 配置将 LoggingAspect bean 声明为切面。首先，我们将 LoggingAspect 声明为 bean。然后我们用 @Aspect 注释对该 bean 进行注释。

我们用 @Before 注释对 LoggingAspect 的 logBeforeTransfer() 进行注释，以便在执行 transferAmount() 之前调用此方法。这称为建议之前。然后，我们用 @After 注解对 LoggingAspect 的 another 方法进行注解，以声明 logAfterTransfer() 方法应该在 transferAmount() 执行后被调用。这称为建议后。

@EnableAspectJAutoProxy 用于在应用程序中启用 Spring AOP 功能。这个注解实际上强制你对spring配置文件中定义的一些组件应用代理。稍后我们将在 第 6 章中详细讨论 Spring AOP，使用代理和装饰器模式的Spring Aspect Oriented Programming。现在，知道你已经要求 Spring 调用 logBeforeTransfer() 和 logAferTransfer() 就足够了TransferService 类的 transferAmount() 方法前后的="literal">LoggingAspect。现在，从这个例子中可以看出两个重要的点：

• LoggingAspect is still a POJO (if you ignore the @Aspect annotation or are using XML-based configuration)--nothing about it indicates that it's to be used as an aspect.
• It is important to remember that LoggingAspect can be applied to TransferService without TransferService needing to explicitly call it. In fact, TransferService remains completely unaware of the existence of LoggingAspect.

让我们转向另一种 Spring 简化 Java 开发的方式。

在企业应用程序的某一时刻，我们看到了一些看起来像我们之前在同一个应用程序中编写过的代码。这实际上是样板代码。我们经常不得不在同一个应用程序中一次又一次地编写代码，以完成应用程序不同部分的共同需求。不幸的是，有很多地方 Java API 涉及到一堆样板代码。当使用 JDBC 从数据库中查询数据时，可以看到样板代码的一个常见示例。如果您曾经使用过 JDBC，那么您可能已经在代码中编写了一些处理以下内容的内容：

让我们看看下面的代码，它包含 Java 的 JDBC API 的样板代码：

    public Account getAccountById(long id) { 
      Connection conn = null; 
      PreparedStatement stmt = null; 
      ResultSet rs = null; 
      try { 
        conn = dataSource.getConnection(); 
        stmt = conn.prepareStatement( 
          "select id, name, amount from " + 
          "account where id=?"); 
        stmt.setLong(1, id); 
        rs = stmt.executeQuery(); 
        Account account = null; 
        if (rs.next()) { 
          account = new Account(); 
          account.setId(rs.getLong("id")); 
          account.setName(rs.getString("name")); 
          account.setAmount(rs.getString("amount")); 
        } 
        return account; 
      } catch (SQLException e) { 
      } finally { 
          if(rs != null) { 
            try { 
              rs.close(); 
            } catch(SQLException e) {} 
          } 
          if(stmt != null) { 
            try { 
              stmt.close(); 
            } catch(SQLException e) {} 
          } 
          if(conn != null) { 
            try { 
              conn.close(); 
            } catch(SQLException e) {} 
          } 
        } 
      return null; 
    } 

在上述代码中，我们可以看到 JDBC 代码向数据库查询帐户名称和金额。对于这个简单的任务，我们必须创建一个连接，然后创建一个语句，最后查询结果。我们还必须捕获 SQLException，这是一个检查异常，即使如果它被抛出，您也无能为力。最后，我们必须清理混乱，关闭连接语句和结果集。这也可能迫使它处理 JDBC 的异常，因此您也必须在此处捕获 SQLException。这种样板代码严重损害了可重用性。

Spring JDBC 使用模板设计模式解决了样板代码的问题，并通过删除模板中的通用代码使生活变得非常简单。这使得数据访问代码非常干净，并防止了诸如连接泄漏等烦人的问题，因为 Spring 框架确保所有数据库资源都被正确释放。

    public Account getAccountById(long id) { 
      return jdbcTemplate.queryForObject( 
        "select id, name, amoount" + 
        "from account where id=?", 
         new RowMapper<Account>() { 
           public Account mapRow(ResultSet rs, 
            int rowNum) throws SQLException { 
              account = new Account(); 
              account.setId(rs.getLong("id")); 
              account.setName(rs.getString("name")); 
              account.setAmount(rs.getString("amount")); 
              return account; 
            } 
         }, 
      id); 
    } 

在 Spring Framework 中，org.springframework.beans.factory.BeanFactory 接口提供了 bean factory，它是一个 Spring IoC 容器。 XmlBeanFactory 是这个接口的一个实现类。此容器从 XML 文件中读取配置元数据。它基于 GOF 工厂方法设计模式——它以复杂的方式创建、管理、缓存和连接应用程序对象。 bean 工厂只是一个对象池，对象由配置创建和管理。对于小型应用来说，这已经足够了，但是企业应用的需求更多，所以spring提供了另外一个版本的spring容器，功能更多。

在下一节中，我们将了解应用程序上下文以及 Spring 如何在应用程序中创建它。

在 Spring Framework 中，org.springframework.context.ApplicationContext 接口也提供了 Spring 的 IoC 容器。它只是 bean 工厂的一个包装器，提供一些额外的应用程序上下文服务，例如对 AOP 的支持，因此也提供声明性事务、安全性和仪表支持，例如对国际化所需的消息资源的支持，以及发布应用程序的能力事件到感兴趣的事件侦听器。

Spring 提供了几种风格的应用程序上下文作为 bean 容器。 ApplicationContext 接口有多个核心实现，如下所示：

Spring 为您提供了 ApplicationContext 接口的 Web 感知实现，如下所示：

我们可以使用这些实现中的任何一种将 bean 加载到 bean 工厂中。这取决于我们的应用程序配置文件位置。例如，如果您想从特定位置的文件系统中加载配置文件 spring.xml，Spring 为您提供了一个 FileSystemXmlApplicationContext< /code>，在文件系统的特定位置查找配置文件 spring.xml 的类：

    ApplicationContext context = new
     FileSystemXmlApplicationContext("d:/spring.xml"); 

同样，您还可以使用 ClassPathXmlApplicationContext 从应用程序的类路径中加载应用程序配置文件 spring.xml Spring 提供的类。它在类路径（包括 JAR 文件）的任何位置查找配置文件 spring.xml：

    ApplicationContext context = new 
     ClassPathXmlApplicationContext("spring.xml"); 

如果您使用的是 Java 配置而不是 XML 配置，则可以使用 AnnotationConfigApplicationContext：

    ApplicationContext context = new 
     AnnotationConfigApplicationContext(AppConfig.class); 

加载配置文件并获取应用上下文后，我们可以通过调用应用上下文的 getBean() 方法从 Spring 容器中获取 bean：

    TransferService transferService = 
     context.getBean(TransferService.class); 

在下一节中，我们将了解 Spring bean 的生命周期，以及 Spring 容器如何响应 Spring bean 来创建和管理它。

Spring框架的这个模块使用了很多设计模式，如工厂方法设计模式、DI模式、抽象工厂设计模式、单例设计模式、原型设计模式等。所有其他 Spring 模块都依赖于该模块。当您配置应用程序时，您将隐式使用这些类。它也称为 IoC 容器，是 Spring 支持依赖注入的核心，它管理 Spring 应用程序中的 bean 如何创建、配置和管理。您可以使用 BeanFactory 的实现或 ApplicationContext 的实现来创建 Spring 容器。该模块包含 Spring bean factory，它是提供 DI 的 Spring 部分。

Spring AOP 是一个基于 Java 的 AOP 框架，集成了 AspectJ。它使用动态代理进行切面编织，专注于使用 AOP 解决企业问题。该模块基于代理和装饰器设计模式。该模块实现了横切关注点的模块化，以避免缠结并消除分散。与 DI 一样，它支持核心业务服务和横切关注点之间的松散耦合。您可以实现自定义方面并在应用程序中以声明方式配置它们，而不会影响业务对象的代码。它在代码中提供了很大的灵活性；您可以在不触及业务对象代码的情况下删除或更改方面逻辑。这是spring框架中非常重要的一个模块，所以我会在第6章中详细讨论，本书的Spring Aspect Oriented Programming with Proxy and Decorator Pattern。

Spring DAO 和 Spring JDBC 通过使用模板删除公共代码，让生活变得非常轻松。模板实现了 GOF 模板方法设计模式，并提供了合适的扩展点来插入自定义代码。如果您使用的是传统的 JDBC 应用程序，则必须编写大量样板代码，例如创建数据库连接、创建语句、查找结果集、处理 SQLException，最后关闭连接。如果您正在使用带有 DAO 层的 Spring JDBC 框架，那么您不必编写样板代码，这与传统的 JDBC 应用程序不同。这意味着 Spring 允许您保持应用程序代码简洁明了。

Spring 还提供了对 ORM 解决方案的支持，它提供了与 ORM 工具的集成，以便在关系数据库中轻松持久化 POJO 对象。这个模块实际上提供了对 Spring DAO 模块的扩展。与基于 JDBC 的模板一样，Spring 提供 ORM 模板以与领先的 ORM 产品一起使用，例如 Hibernate、JPA、OpenJPA、TopLink、iBATIS 等。

Spring 为企业 Web 应用程序提供了一个 Web 和远程模块。该模块有助于构建高度灵活的 Web 应用程序，利用 Spring IOC 容器的全部优势。 Spring的这个模块使用了MVC架构模式、前端控制器模式、DispatcherServlet模式等模式，并与servlet API无缝集成。 Spring Web 模块非常可插拔且灵活。我们可以添加任何视图技术，例如 JSP、FreeMarker、Velocity 等。我们还可以使用 Spring IOC 和 DI 将其与其他框架集成，例如 Struts、Webwork 和 JSF。