什么是Spring_taco项目-CSDN博客

推荐两本书：《Spring实战》 + 《Spring揭秘》

第一本告诉你怎么用Spring

第二本给你简单展示如何用的同时，还告诉你Spring是怎么实现的

1.1 什么是Spring

Spring的核心是提供了一个容器（container），通常称为Spring应用上下文（Spring applicationcontext），它们会创建和管理应用组件。

这些组件也可以称为bean，会在Spring应用上下文中装配在一起，从而形成一个完整的应用程序。这就像砖块、砂浆、木材、管道和电线组合在一起，形成一栋房子似的。

将bean装配在一起的行为是通过一种基于依赖注入（dependency injection，DI）的模式实现的。

举例来说，假设在应用的众多组件中，有两个是我们需要处理的：库存服务（用来获取库存水平）和商品服务（用来提供基本的商品信息）。商品服务需要依赖于库存服务，这样它才能提供商品的完整信息。图1.1阐述这些bean和Spring应用上下文之间的关系。

在历史上，指导Spring应用上下文将bean装配在一起的方式是使用一个或多个XML文件（描述各个组件以及它们与其他组件的关联关系）。例如，如下的XML描述了两个bean，也就是InventoryService bean和ProductService bean，并且通过构造器参数将InventoryService装配到了ProductService中：

但是，在最近的Spring版本中，基于Java的配置更为常见。如下基于Java的配置类是与XML配置等价的：

@Configuration注解会告知Spring这是一个配置类，会为Spring应用上下文提供bean。这个配置类的方法使用@Bean注解进行了标注，表明这些方法所返回的对象会以bean的形式添加到Spring的应用上下文中（默认情况下，这些bean所对应的bean ID与定义它们的方法名称是相同的）。

相对于基于XML的配置方式，基于Java的配置会带来多项额外的收益，包括更强的类型安全性以及更好的重构能力。即便如此，不管是使用Java还是使用XML的显式配置，只有当Spring不能进行自动配置的时候才是必要的。

在Spring技术中，自动配置起源于所谓的自动装配（autowiring）和组件扫描（componentscanning）。借助组件扫描技术，Spring能够自动发现应用类路径下的组件，并将它们创建成Spring应用上下文中的bean。借助自动装配技术，Spring能够自动为组件注入它们所依赖的其他bean。

最近，随着Spring Boot的引入，自动配置的能力已经远远超出了组件扫描和自动装配。Spring Boot是Spring框架的扩展，提供了很多增强生产效率的方法。最为大家所熟知的增强方法就是自动配置（autoconfiguration），Spring Boot能够基于类路径中的条目、环境变量和其他因素合理猜测需要配置的组件并将它们装配在一起。

1.2 初始化Spring应用

在本书中，我们将会创建一个名为Taco Cloud的在线应用，它能够订购人类所发明的一种美味，也就是墨西哥煎玉米卷（taco）[插图]。当然，在这个过程中，为了达成我们的目标，我们将会用到Spring、Spring Boot以及各种相关的库和框架。

1.2.2 检查Spring项目的结构

项目加载到IDE中之后，我们将其展开，看一下其中都包含什么内容。图1.6展现了Spring Tool Suite中已展开的Taco Cloud项目。

你可能已经看出来了，这就是一个典型的Maven或Gradle项目结构，其中应用的源码放到了“src/main/java”中，测试代码放到了“src/test/java”中，而非Java的资源放到了“src/main/resources”。在这个项目结构中，我们需要注意以下几点。

•mvnw和mvnw.cmd：这是Maven包装器（wrapper）脚本。借助这些脚本，即便你的机器上没有安装Maven，也可以构建项目。

•pom.xml：这是Maven构建规范，随后我们将会深入介绍该文件。

•TacoCloudApplication.java：这是Spring Boot主类，它会启动该项目。随后，我们会详细介绍这个类。

•application.properties：这个文件起初是空的，但是它为我们提供了指定配置属性的地方。在本章中，我们会稍微修改一下这个文件，但是我会将配置属性的详细阐述放到第5章。•static：在这个文件夹下，你可以存放任意为浏览器提供服务的静态内容（图片、样式表、JavaScript等），该文件夹初始为空。

•templates：这个文件夹中存放用来渲染内容到浏览器的模板文件。这个文件夹初始是空的，不过我们很快就会往里面添加Thymeleaf模板。

•TacoCloudApplicationTests.java：这是一个简单的测试类，它能确保Spring应用上下文可以成功加载。在开发应用的过程中，我们会将更多的测试添加进来。

随着Taco Cloud应用功能的增长，我们会不断使用Java代码、图片、样式表、测试以及其他附属内容来充实这个项目结构。不过，在此之前，我们先看一下Spring Initializr提供的几个条目。

在pom.xml文件中，我们第一个需要注意的地方就是<packaging>。我们选择了将应用构建成一个可执行的JAR文件，而不是WAR文件。这可能是你所做出的最奇怪的选择之一，对Web应用来说尤为如此。毕竟，传统的Java Web应用都是打包成WAR文件，JAR只是用来打包库和较为少见的桌面UI应用的。

打包为JAR文件是基于云思维做出的选择。尽管WAR文件非常适合部署到传统的Java应用服务器上，但对于大多数云平台来说它们并不是理想的选择。有些云平台（比如Cloud Foundry）也能够部署和运行WAR文件，但是所有的Java云平台都能够运行可执行的JAR文件。因此，Spring Initializr默认会使用基于JAR的打包方式，除非我们明确告诉它采用其他的方式。

如果你想要将应用部署到传统的Java应用服务器上，那么需要选择使用基于WAR的打包方式并要包含一个Web初始化类。在第2章中，我们将会更详细地了解如何构建WAR文件。

接下来，请留意<parent>元素，更具体来说是它的<version>子元素。这表明我们的项目要以spring-boot-starter-parent作为其父POM。除了其他的一些功能之外，这个父POM为Spring项目常用的一些库提供了依赖管理，现在你不需要指定它们的版本，因为这是通过父POM来管理的。这里的2.0.4.RELEASE表明要使用Spring Boot 2.0.4，所以会根据这个版本的Spring Boot定义来继承依赖管理。'

既然我们谈到了依赖的话题，那么需要注意在<dependencies>元素下声明了3个依赖。在某种程度上，你可能会对前两个更熟悉一些。它们直接对应我们在Spring Tool Suite新项目向导中点击Finish之前所选择的Web和Thymeleaf依赖。第三个依赖提供了很多有用的测试功能。我们没有必要在专门的复选框中选择它，因为Spring Initializr假定你将会编写测试（希望你会正确地开展这项工作）。你可能也会注意到这3个依赖的artifact ID上都有starter这个单词。Spring Boot starter依赖的特别之处在于它们本身并不包含库代码，而是传递性地拉取其他的库。这种starter依赖主要有3个好处。

•构建文件会显著减小并且更易于管理，因为这样不必为每个所需的依赖库都声明依赖。

•我们能够根据它们所提供的功能来思考依赖，而不是根据库的名称。如果是开发Web应用，那么你只需要添加web starter就可以了，而不必添加一堆单独的库再编写Web应用。

•我们不必再担心库版本的问题。你可以直接相信给定版本的Spring Boot，传递性引入的库的版本是兼容的。现在，你只需要关心使用的是哪个版本的Spring Boot就可以了。

最后，构建规范还包含一个Spring Boot插件。这个插件提供了一些重要的功能。