Spring - My Notes
Spring - My Notes
Spring - My Notes
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!
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 .xml files 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.
Spring MVC
Spring MVC is built around the browser as a platform, and it organizes these roles
like this:
HTML templates are the views - each one represents a specific screen or screen
component that the user is shown.
In the template, we need to add Thymeleaf attributes to our HTML. In our
example so far, we added the th:text attribute to the heading we want to
be dynamic, like so:
th:text attribute ( ${welcomeMessage} ). The syntax of this expression is fairly
simple: the ${} indicates an expression to evaluate, and by using
a name like welcomeMessage inside of it, we're telling Thymeleaf to look up a
value in the model supplied for this template with the same name.
The key elements to focus on are the new arguments to each of these methods -
the MessageForm class is a POJO specifically designed to hold the form data we
defined in the previous video.
For the GET request handling method, we declare the MessageForm argument to
ensure that the object exists and is added to the model by Spring automatically. This
is necessary, because Thymeleaf needs an object with the name newMessage to be
present in the model to render properly, even if there isn't any data in the object yet.
For the POST request handling method, we declare the MessageForm argument to tell
Spring that it should look for data that matches that in the body of the request we're
handling. Spring will then automatically extract that data and put it in
a MessageForm object before calling our method, passing it to us so we can use the
data as we see fit.
In both cases, we're annotating this argument with @ModelAttribute . This allows us
to specify that Spring should add the object to our Model before asking Thymeleaf to
render the template. That means we don't have to add it manually! Pretty handy.
NEXT
Security