1.1.2 审视Spring Boot要点

  Spring Boot为Spring应用程序开发带来了伟大的魔法。它的执行具备了以下4个核心手段:

*  自动配置——Spring Boot可以按应用程序功能性自动进行配置,这普遍适用于多数Spring应用程序。
*  启动依赖——你可告诉Spring Boot你需要什么功能,它将会确保将需要的库添加进来以构建项目。
*  命令行接口——这一个特点可以让你只需写完整的应用程序代码,而无需关心传统项目的构建。
*  执行器——让你深入了解执行Spring Boot应用程序中发生了什么。  

  每个功能都以其自己的方式简化Spring应用程序的开发。我们将在整本书中逐步运用他们。 但现在,让我们快速浏览一下他们各提供了什么。

自动配置

  In any given Spring application’s source code, you’ll find either Java configuration or XML configuration (or both) that enables certain supporting features and functionality for the application. For example, if you’ve ever written an application that accesses a relational database with JDBC , you’ve probably configured Spring’s JdbcTemplate as a bean in the Spring application context. I’ll bet the configuration looked a lot like this:

 @Bean
 public JdbcTemplate jdbcTemplate(DataSource dataSource) {
        return new JdbcTemplate(dataSource);
  }

  This very simple bean declaration creates an instance of JdbcTemplate , injecting it with its one dependency, a DataSource . Of course, that means that you’ll also need to configure a DataSource bean so that the dependency will be met. To complete this configuration scenario, suppose that you were to configure an embedded H2 database as the DataSource bean:

@Bean
public DataSource dataSource() {
  return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.H2)
            .addScripts('schema.sql', 'data.sql')
            .build();
}

  This bean configuration method creates an embedded database, specifying two SQL scripts to execute on the embedded database. The build() method returns a Data- Source that references the embedded database.   Neither of these two bean configuration methods is terribly complex or lengthy. But they represent just a fraction of the configuration in a typical Spring application. Moreover, there are countless Spring applications that will have these exact same methods. Any application that needs an embedded database and a JdbcTemplate will need those methods. In short, it’s boilerplate configuration.
  If it’s so common, then why should you have to write it?   Spring Boot can automatically configure these common configuration scenarios. If Spring Boot detects that you have the H2 database library in your application’s class- path, it will automatically configure an embedded H2 database. If JdbcTemplate is in the classpath, then it will also configure a JdbcTemplate bean for you. There’s no need for you to worry about configuring those beans. They’ll be configured for you, ready to inject into any of the beans you write.
  There’s a lot more to Spring Boot auto-configuration than embedded databases and JdbcTemplate . There are several dozen ways that Spring Boot can take the bur- den of configuration off your hands, including auto-configuration for the Java Persis- tence API ( JPA ), Thymeleaf templates, security, and Spring MVC . We’ll dive into auto- configuration starting in chapter 2.

启动依赖

  It can be challenging to add dependencies to a project’s build. What library do you need? What are its group and artifact? Which version do you need? Will that version play well with other dependencies in the same project?
  Spring Boot offers help with project dependency management by way of starter dependencies. Starter dependencies are really just special Maven (and Gradle) depen- dencies that take advantage of transitive dependency resolution to aggregate com- monly used libraries under a handful of feature-defined dependencies.
  For example, suppose that you’re going to build a REST API with Spring MVC that works with JSON resource representations. Additionally, you want to apply declarative validation per the JSR-303 specification and serve the application using an embedded Tomcat server. To accomplish all of this, you’ll need (at minimum) the following eight dependencies in your Maven or Gradle build:

* org.springframework:spring-core
* org.springframework:spring-web
* org.springframework:spring-webmvc
* com.fasterxml.jackson.core:jackson-databind
* org.hibernate:hibernate-validator
* org.apache.tomcat.embed:tomcat-embed-core
* org.apache.tomcat.embed:tomcat-embed-el
* org.apache.tomcat.embed:tomcat-embed-logging-juli

  On the other hand, if you were to take advantage of Spring Boot starter dependencies, you could simply add the Spring Boot “web” starter ( org.springframework.boot:spring-boot-starter-web ) as a build dependency. This single dependency will transitively pull in all of those other dependencies so you don’t have to ask for them all.
  But there’s something more subtle about starter dependencies than simply reduc- ing build dependency count. Notice that by adding the “web” starter to your build, you’re specifying a type of functionality that your application needs. Your app is a web application, so you add the “web” starter. Likewise, if your application will use JPA per- sistence, then you can add the “jpa” starter. If it needs security, you can add the “secu- rity” starter. In short, you no longer need to think about what libraries you’ll need to support certain functionality; you simply ask for that functionality by way of the perti- nent starter dependency.
  Also note that Spring Boot’s starter dependencies free you from worrying about which versions of these libraries you need. The versions of the libraries that the start- ers pull in have been tested together so that you can be confident that there will be no incompatibilities between them.
  Along with auto-configuration, we’ll begin using starter dependencies right away, starting in chapter 2.

命令行接口

  In addition to auto-configuration and starter dependencies, Spring Boot also offers an intriguing new way to quickly write Spring applications. As you saw earlier in section 1.1, the Spring Boot CLI makes it possible to write applications by doing more than writing the application code.
  Spring Boot’s CLI leverages starter dependencies and auto-configuration to let you focus on writing code. Not only that, did you notice that there are no import lines in list- ing 1.1? How did the CLI know what packages RequestMapping and RestController come from? For that matter, how did those classes end up in the classpath?
  The short answer is that the CLI detected that those types are being used, and it knows which starter dependencies to add to the classpath to make it work. Once those dependencies are in the classpath, a series of auto-configuration kicks in and ensures that DispatcherServlet and Spring MVC are enabled so that the controller can respond to HTTP requests.
  Spring Boot’s CLI is an optional piece of Spring Boot’s power. Although it provides tremendous power and simplicity for Spring development, it also introduces a rather unconventional development model. If this development model is too extreme for your taste, then no problem. You can still take advantage of everything else that Spring Boot has to offer even if you don’t use the CLI . But if you like what the CLI pro- vides, you’ll definitely want to look at chapter 5 where we’ll dig deeper into Spring Boot’s CLI .

执行器

  The final piece of the Spring Boot puzzle is the Actuator. Where the other parts of Spring Boot simplify Spring development, the Actuator instead offers the ability to inspect the internals of your application at runtime. With the Actuator installed, you can inspect the inner workings of your application, including details such as

  • What beans have been configured in the Spring application context
  • What decisions were made by Spring Boot’s auto-configuration
  • What environment variables, system properties, configuration properties, and
  • command-line arguments are available to your application
  • The current state of the threads in and supporting your application A trace of recent HTTP requests handled by your application
  • Various metrics pertaining to memory usage, garbage collection, web requests,and data source usage

  The Actuator exposes this information in two ways: via web endpoints or via a shell interface. In the latter case, you can actually open a secure shell ( SSH ) into your appli- cation and issue commands to inspect your application as it runs.
  We’ll explore the Actuator’s capabilities in detail when we get to chapter 7.

results matching ""

    No results matching ""