Spring boot for web development

Spring Boot Basics for Web Development

The Spring Framework

The Spring Transformation

The figure above shows that Spring takes the component class files and dependency configuration from the developer and instantiates a system of Java objects with references to each other.

Of all the tools we’ll be using in this course, Spring is the most important because it defines our entire style of application development. Spring is a framework for Inversion of Control, which means that to use it, we have to package our code into individual component classes, telling Spring which components need each other to function. Spring takes the component classes we define and the dependencies we define between them and instantiates a system of matching Java objects with references to each other. This frees us from having to write so-called “glue code” to instantiate, connect, and manage components manually, and allows us to instead focus on writing so-called business logic, or code that concerns itself exclusively on the conceptual model of the application.

Key Terms

Inversion of Control (IoC): A design pattern in which the developer creates independent application components and uses a framework to connect them, rather than writing the integration code themselves

• Business Logic: Code that relates exclusively to an application’s conceptual model and featureset. Contrast with utility code like database access, HTTP request parsing, etc.
• Persistent Components: Java Objects that Spring maintains over time; they’re persistent because they’re created and maintained for as long as the application needs them to be.
• Dependency Injection: A mechanism by which IoC may be implemented. Components are configured with dependencies on other components, which are injected at runtime. Injection is quite literal — a component’s dependencies are usually expressed as annotated fields on the component class, and Spring will populate those fields with the dependencies at runtime.

What is Spring

https://github.com/resisttheurge/uda

When designing Spring applications, the most important principle to keep in mind is separation of concerns. What that really means is that for every problem your application has to solve has a home in a component class that is easy to find and flexible to use. By building your application out of small but focused components, you’ll make the most of Spring’s boilerplate-crushing power, and when it’s time to add new features, you’ll know exactly where to put them. On a larger team, this means greater coordination and less time spent trying to find and eliminate redundancies and conflicts.

But in order to allow your components to communicate effectively with one another, you’ll need a system of data types to share between them. These are simple classes designed to store structured data, and little else. They’re useful as conceptual representations of application data, like user profiles, or shipment invoice details, but made to be used and manipulated by the components of an application. A good rule of thumb to decide which is which is the new keyword test. A component should never be manually instantiated with the new keyword - components are managed by Spring, which means we need to rely on dependency injection to get a component reference. Data types, on the other hand, are no more special than Java's collections, and we can manually instantiate them with the new keyword whenever we'd like.

Key Terms:

• Separation of Concerns: A code organization philosophy that emphasizes single-purpose components. In Java and Spring, this means keeping all methods related to a specific problem domain in the same class, for the sake of maintainability and reducing code reuse.
• Data Types: Sometimes called POJOs (plain-old-java-objects), Data Types are classes in application designed purely to hold structured application data, like users, profiles, or anything else an application might manage. These objects are helpful for us to maintain a good conceptual model of an application, and are created and accessed frequently during execution.
• Components: Components are persistent class instances managed by Spring in an application. They usually resemble libraries more than typical objects, with methods that must be called to perform specific actions. Components are only created when Spring is configured to create them, usually at server startup.

Spring Boot IoC Configuration

Under the hood, Spring is just a Java application itself — and it responds to our configuration in a predictable way. When a Spring application starts, it scans your code base for specially-marked class files and configuration options. It uses that information to instantiate your application components as Java objects, and it stores them in a special data structure called the application context. This context is ultimately very similar to a Map or a python dictionary, and it can be queried at runtime to find specific components when needed. This is a closed system, so components instantiated outside of Spring won't automatically be injected with dependencies like those instantiated by Spring. Mind the new keyword!

https://github.com/udacity/nd035-c1-spring-boot-basics-examples/tree/master/udacity-jwdnd-c1-l2-spring-ioc-config-master

Annotations to begin the Setup process

In a Spring Boot application, the basic setup of the Spring application context has already been done for us. The following annotations are the starting point of an application:

1. @SpringBootApplication - In a generated project starter, you're always given a main application class with the @SpringBootApplication annotation. This annotation is actually equivalent to three other annotations from Spring: @Configuration, @EnableAutoConfiguration, and @ComponentScan. The @SpringBootApplication configures Spring's component scanning and auto-configuration.
2. @Configuration - It tells Spring that the annotated class includes component definitions for Spring to process. These take the form of @Bean-annotated method whose return values are included as components in the application context. These methods can also take parameters, which act like the dependencies of the components returned by the methods.
3. @EnableAutoConfiguration - It tells Spring that it's okay to try to match dependencies to components automatically. Usually, that means dependencies are filled based on type, so in the example above, we have the compoundMessage method which depends on the basicMessageimplicitly - the only String bean that Spring is aware of when constructing the compoundMessage is the basicMessage, so it uses that.

When there are multiple beans that satisfy a specific dependency, Spring’s auto-configuration needs some help to decide which to use. A common solution is to mark a bean with the @Primaryannotation to indicate a universally-preferred bean for its type. Or, you can use pairs of @Qualifierannotations on beans and the dependencies that reference them to gain a finer level of control.

@ComponentScan provides another layer of automation - automatic component scanning throughout your entire code base. But that's a topic for the next video!

The figure above shows an example of how Spring processes an IoC configuration. The general steps are:

• A bean without dependencies is initialized first and placed within the application context.
• A service is instantiated by Spring, and the first bean is retrieved from the app context to be injected as a dependency, after which Spring places the service in the application context.
• Finally, another bean is initialized by Spring, which retrieves the previous two components to be injected as dependencies, after which the new bean is placed in the app context, and the application is fully initialized.

Key Terms

• Configuration Files: Project files that configure some part of Spring’s operation. Some are embedded in Java classes, like we just discussed, and others are .properties, .yaml, and .xmlfiles that we'll discuss later this lesson. Some of them configure the IoC context, like the ones we just discussed, and others configure more abstract pieces of Spring's system.
• Component Annotations: Component annotations are annotations that identify application components for Spring to manage. @Bean and @Configuration are examples from the most recent videos, and in the next section we'll discuss @Component and @Service as well.
• Application Context: Spring’s application context is just a giant data structure that holds all application component instances. It can be queried to gain access to a specified component at runtime, and it’s what Spring uses to resolve dependencies.
• Beans: “Beans” are Spring’s name for generic application components, and include any value Spring has stored in the application context. A bean is always either an object or primitive value.
• Closed System: Spring’s application context is a closed system, which means that it manages all of the components stored within. It is not possible to instantiate a component manually and still link it fully with Spring — it will never be aware of the components inside of Spring’s application context, and vice versa.
• @SpringBootApplication: An annotation put on the main application class of a Spring Boot project. It serves as an alias of three other annotations, @Configuration, @EnableAutoConfiguration, and @ComponentScan
• @Configuration: A class annotated with @Configuration is instantiated and managed by Spring as a component, but also as a bean factory. Any methods of the configuration class that are annotated with @Bean are used by Spring to create new beans to add to the application context.
• @Bean: A method annotated with @Bean inside of a configuration class will be used by Spring to generate a bean of the method's return type. This means that the developer can manually configure beans to be included in the application context.
• @EnableAutoConfiguration: A class annotated with @EnableAutoConfiguration tells Spring to try to automatically match beans to dependencies based primarily on type. This reduces the need for boilerplate code explicitly identifying individual beans as dependencies.
• @Primary: This annotation distinguishes the annotated bean method as the default dependency of its type. This is used to resolve conflicts that arise from having multiple bean definitions of the same type when auto configuration is enabled.
• @Qualifier: This annotation distinguishes the annotated bean method or dependency declaration as a qualified bean or dependency. Qualified beans are considered for unqualified dependencies, but only matching qualified beans are considered for qualified dependencies. You can read more about it here(https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-autowired-annotation-qualifiers)

Components and Services

If we want to declare custom classes as Spring Components, the best way to do it is to make use of @ComponentScan, an annotation that tells Spring to search your code base for classes annotated with @Component. These classes will automatically be instantiated as Spring beans, so there's no need to define an @Bean-annotated method if you already have @Component on you classes. There are other variants of @Component that identify specific roles for each component to play. We'll see some examples of these in the coming lectures, but if you want to learn more, check out the link below.

One important thing to keep in mind is that @ComponentScan only marks the package of the class it's annotating for scanning - any classes outside of that package or its subpackages will be excluded by Spring. Here are the official Spring docs for @ComponentScan as well as the official Spring docs explaining the how different stereotype annotations like @Component, @Service, @Repository, and others, function.

Onion Architecture

The figure above shows the basic structure of Onion Architecture. External requests must first pass through a layer of controllers or request handlers whose only purpose is to handle these external requests. These controllers then use the next layer of the onion, the services, to process the actions or analysis triggered by the request. The services, in turn, use each other and the next layer, repositories and data access, to persist the results of the actions triggered by the request.

Key Terms

• Onion Architecture: An architectural pattern in which an application is separated into nested layers. In order for a request to be processed by the application, it must first travel through an outer layer of external interfaces and controllers, then through a middle layer of services and business logic, and finally through a persistence layer of data access objects. The separation of these layers emphasizes clean separation of concerns.
• Application Component: In Spring, this is any @Component-annotated class that is instantiated by Spring and placed in Spring’s application context. Architecturally speaking, this is a logical unit of an application — a single-purpose library or object that solves a particular problem an application faces.
• Service: In Spring, this is any @Service-annotated class, handled identically to an @Component-annotated class. The difference between the two is semantics - a component is the most generic type of bean, and can be any kind of shared application structure. A service is specifically a collection of library methods that manage one aspect of an application's business logic. For example, a UserService would expose high-level actions related to the users of an application, and an AuthenticationService would expose actions for registering and authenticating a user. Services represent the middle layer of an onion architecture, and should contain the bulk of an application's business logic.

Repository: In Spring, an @Repository-annotated class is treated identically to an @Component-annotated one, but as with @Service, the semantics are different. In an onion architecture, repositories are the inner layer - each repository should act like an interface to a specific set of stored or persistent data. For example, a UserRepository would expose an interface capable of create/read/update/delete and query operations on the users table of the database.

Solution: Components and Services

There are quite a few classes in this example, but only some of them need annotations. We can figure out which ones by following the chain of dependencies — FoodController references FoodService which references FoodRepository, which means all of them need some variation of @Component on each. Yes, even FoodController at the top of the chain - remember that in order for Spring fill dependencies, all related components must be configured for IoC.

We also need to annotate our main application class with @SpringBootApplication. Remember that this is what configures Spring's component scanning and auto-configuration, so without this, the @Component variants we used above wouldn't be seen by Spring.

ExercisesApplication.java

/**
* This annotation will, among other things, enable component
* scanning for our project
*/
@SpringBootApplication 
public class Course1ExercisesApplication {

  public static void main(String[] args) {
     SpringApplication.run(Course1ExercisesApplication.class, args);
  }

}

FoodController.java

/**
* Controller for receiving requests.
* This class needs to be a Spring Component so that Spring can
* automatically create instances of it to receive web requests. We use
* the @Controller annotation variation of @Component for this purpose.
*/

@Controller
@RequestMapping("/food")
public class FoodController {

   private FoodService foodService;

   public FoodController(FoodService foodService) {
       this.foodService = foodService;
   }

   @GetMapping
   public String getHomePage(FoodForm foodForm, Model model) {
       foodService.addFood(foodForm.getFoodName(), foodForm.getCalories(), foodForm.getMealTime());
       return "foodAdded";
   }

}

FoodService.java

/**
* Food Service that performs business logic operations regarding food
* This class needs to be a component, because our Controller has a reference to
* it that it doesn't create itself. Marking this as a @Service lets Spring know
* to make instances of this bean available to other classes, though @Component would work as well.
*/
@Service
public class FoodService {
   private FoodRepository foodRepository;

   public FoodService(FoodRepository foodRepository) {
       this.foodRepository = foodRepository;
   }

   public Boolean isFoodAvailableAtMealTime(String foodName, MealTime mealTime) {
       return foodRepository.getFood(mealTime).stream()
               .filter(food -> food.getName().equals(foodName))
               .findFirst()
               .isPresent();
   }

   public void addFood(String foodName, Integer calories, MealTime mealTime) {
       foodRepository.addFood(mealTime, new FoodData(foodName, calories));
   }

   public FoodRepository getFoodRepository() {
       return foodRepository;
   }

   public void setFoodRepository(FoodRepository foodRepository) {
       this.foodRepository = foodRepository;
   }
}

FoodRepository.java

/**
* Pretend repository implementation
* This class needs to be a Spring component as well, because our FoodService relies on it. We use
* the @Repository annotation here to denote its function, but for this example @Component would work just
* fine as well.
*/
@Repository
public class FoodRepository {
   private Map<MealTime, List<FoodData>> foodDatabase = new EnumMap<>(MealTime.class);

   public List<FoodData> getFood(MealTime mealTime) {
       return foodDatabase.getOrDefault(mealTime, new ArrayList<>());
   }

   public void addFood(MealTime mealTime, FoodData food) {
       foodDatabase.getOrDefault(mealTime, new ArrayList<>()).add(food);
   }
}

Server-Wide Configuration

https://github.com/udacity/nd035-c1-spring-boot-basics-examples/tree/master/udacity-jwdnd-c1-l2-server-config-master

Spring Boot does a lot to simplify the setup of a new Spring application, but sometimes, you need to change how it works. That’s what the application.properties file is for! You can find it in the src/main/resources folder of a generated Spring Boot project, and it allows you to configure anything from the server's hostname and port to the size and colors of the Spring logo that appears in the console when starting an application.

https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html

Key Terms

• Properties File: A file with the .properties extension that consists of plain-text key=valuepairs separated by new lines. This format is often used by Java libraries and frameworks because it provides a simple way to specify named constants in a plain text file.

Solution: Server-Wide Configuration

application.properies

server.port=8086
logging.level.com.udacity.jdnd.course1exercises=DEBUG
spring.datasource.username=superman
spring.datasource.password=FishTacos1234
spring.thymeleaf.cache=true
spring.devtools.remote.restart.enabled=true

Spring’s intelligent defaults means that your application will often work fine with nothing in your properties file at all! That means we can usually rely on the defaults, and just be ready to look up the properties in the documentation when we need to.

When You have to Use XML Configuration

https://github.com/udacity/nd035-c1-spring-boot-basics-examples/blob/master/udacity-jwdnd-c1-snippets-master/src/main/resources/l2/beans.xml

Spring’s annotation-based configuration is really convenient and allows us to see directly in our Java code how Spring is configured. This is a new API, though, and Spring’s original configuration format was through XML.

We won’t be using this older format in the course, but it’s important to be aware of because it’s still supported by Spring, and many older projects still use it. The key thing to remember is that Spring’s annotation- and XML-based configuration systems are both equally capable of configuring Spring, so if you ever find yourself in a situation where you need one but only know how to do it in the other, you can always find a way to translate between them.

Key Terms

• Legacy: In a programming context, legacy usually refers to older code that still functions or is expected to function, but is on the verge of being made obsolete by newer technologies. A legacy application is one that is no longer being actively built upon, and is instead in maintenance mode.
• XML: eXtensible Markup Language. This is a flexible data format that allows for extension, as the name suggests. Many applications and libraries use XML as a way to store structured application data out of memory, and it’s also a popular data interchange format on the web.

Further Research

https://docs.spring.io/spring-framework/docs/4.3.27.RELEASE/spring-framework-reference/htmlsingle/#beans-annotation-config

Solution: Final Review

https://github.com/udacity/nd035-c1-spring-boot-basics-examples/tree/master/udacity-jwdnd-c1-l2-final-review-solution-master

Glossary

• Inversion of Control (IoC): A design pattern in which the developer creates independent application components and uses a framework to connect them, rather than writing the integration code themselves
• Business Logic: Code that relates exclusively to an application’s conceptual model and featureset. Contrast with utility code like database access, HTTP request parsing, etc.
• Persistent Components: Java Objects that Spring maintains over time; they’re persistent because they’re created and maintained for as long as the application needs them to be.
• Dependency Injection: A mechanism by which IoC may be implemented. Components are configured with dependencies on other components, which are injected at runtime. Injection is quite literal — a component’s dependencies are usually expressed as annotated fields on the component class, and Spring will populate those fields with the dependencies at runtime.
• Separation of Concerns: A code organization philosophy that emphasizes single-purpose components. In Java and Spring, this means keeping all methods related to a specific problem domain in the same class, for the sake of maintainability and reducing code reuse.
• Data Types: Sometimes called POJOs (plain-old-java-objects), Data Types are classes in application designed purely to hold structured application data, like users, profiles, or anything else an application might manage. These objects are helpful for us to maintain a good conceptual model of an application, and are created and accessed frequently during execution.
• Components: Components are persistent class instances managed by Spring in an application. They usually resemble libraries more than typical objects, with methods that must be called to perform specific actions. Components are only created when Spring is configured to create them, usually at server startup.
• Configuration Files: Project files that configure some part of Spring’s operation. Some are embedded in Java classes, like we just discussed, and others are .properties, .yaml, and .xmlfiles that we'll discuss later this lesson. Some of them configure the IoC context, like the ones we just discussed, and others configure more abstract pieces of Spring's system.
• Component Annotations: Component annotations are annotations that identify application components for Spring to manage. @Bean and @Configuration are examples from the most recent videos, and in the next section we'll discuss @Component and @Service as well.
• Application Context: Spring’s application context is just a giant data structure that holds all application component instances. It can be queried to gain access to a specified component at runtime, and it’s what Spring uses to resolve dependencies.
• Beans: “Beans” are Spring’s name for generic application components, and include any value Spring has stored in the application context. A bean is always either an object or primitive value.
• Closed System: Spring’s application context is a closed system, which means that it manages all of the components stored within. It is not possible to instantiate a component manually and still link it fully with Spring — it will never be aware of the components inside of Spring’s application context, and vice versa.
• @SpringBootApplication: An annotation put on the main application class of a Spring Boot project. It serves as an alias of three other annotations, @Configuration, @EnableAutoConfiguration, and @ComponentScan
• @Configuration: A class annotated with @Configuration is instantiated and managed by Spring as a component, but also as a bean factory. Any methods of the configuration class that are annotated with @Bean are used by Spring to create new beans to add to the application context.
• @Bean: A method annotated with @Bean inside of a configuration class will be used by Spring to generate a bean of the method's return type. This means that the developer can manually configure beans to be included in the application context.
• @EnableAutoConfiguration: A class annotated with @EnableAutoConfiguration tells Spring to try to automatically match beans to dependencies based primarily on type. This reduces the need for boilerplate code explicitly identifying individual beans as dependencies.
• @Primary: This annotation distinguishes the annotated bean method as the default dependency of its type. This is used to resolve conflicts that arise from having multiple bean definitions of the same type when auto configuration is enabled.
• @Qualifier: This annotation distinguishes the annotated bean method or dependency declaration as a qualified bean or dependency. Qualified beans are considered for unqualified dependencies, but only matching qualified beans are considered for qualified dependencies. You can read more about it here(https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-autowired-annotation-qualifiers).
• Onion Architecture: An architectural pattern in which an application is separated into nested layers. In order for a request to be processed by the application, it must first travel through an outer layer of external interfaces and controllers, then through a middle layer of services and business logic, and finally through a persistence layer of data access objects. The separation of these layers emphasizes clean separation of concerns.
• Application Component: In Spring, this is any @Component-annotated class that is instantiated by Spring and placed in Spring’s application context. Architecturally speaking, this is a logical unit of an application — a single-purpose library or object that solves a particular problem an application faces.
• Service: In Spring, this is any @Service-annotated class, handled identically to an @Component-annotated class. The difference between the two is semantics - a component is the most generic type of bean, and can be any kind of shared application structure. A service is specifically a collection of library methods that manage one aspect of an application's business logic. For example, a UserService would expose high-level actions related to the users of an application, and an AuthenticationService would expose actions for registering and authenticating a user. Services represent the middle layer of an onion architecture, and should contain the bulk of an application's business logic.
• Repository: In Spring, an @Repository-annotated class is treated identically to an @Component-annotated one, but as with @Service, the semantics are different. In an onion architecture, repositories are the inner layer - each repository should act like an interface to a specific set of stored or persistent data. For example, a UserRepository would expose an interface capable of create/read/update/delete and query operations on the users table of the database.
• Properties File: A file with the .properties extension that consists of plain-text key=valuepairs separated by new lines. This format is often used by Java libraries and frameworks because it provides a simple way to specify named constants in a plain text file.
• Legacy: In a programming context, legacy usually refers to older code that still functions or is expected to function, but is on the verge of being made obsolete by newer technologies. A legacy application is one that is no longer being actively built upon, and is instead in maintenance mode.
• XML: eXtensible Markup Language. This is a flexible data format that allows for extension, as the name suggests. Many applications and libraries use XML as a way to store structured application data out of memory, and it’s also a popular data interchange format on the web.