Spring is for the lazy. Fundamentals, basic concepts and examples with code. Part 1

Many people, after reading my articles about creating a template for a web project and about creating a simple web service using servlets , wondered when I would write about Spring. I didn’t want to, I suggested reading a book (and I still say that a book is better than 10, or even 100 articles on the Internet). But now I’ve decided that explaining the same thing to different people, I spend more time than if I sat down once and wrote an article, and then just posted a link to it. So I’m writing for the sake of the link)). In this article I will not write how to make a working project in Spring in 5 minutes following my example. I will write only about basic things, without knowledge of which it is certainly possible to start a project, but what is happening there, and, more importantly, why, will not be clear.

What is Spring Framework?

Spring Framework , or simply Spring , is one of the most popular frameworks for creating web applications in Java. A framework is something similar to a library (perhaps this term is more familiar to you), but there is one point. Roughly speaking, using a library, you simply create objects of the classes that are in it, call the methods you need, and thus get the result you need. That is, there is a more imperative approach: you clearly indicate in your program at what specific moment you need to create which object, at what moment you need to call a specific method, etc. With frameworks, things are slightly different. You simply write some of your own classes, write some part of the logic there, and the framework itself creates objects of your classes and calls methods for you. Most often, your classes implement some interfaces from the framework or inherit some classes from it, thus receiving some of the functionality already written for you. But it doesn't have to be that way. In Spring, for example, they try to move away from such strict coupling as much as possible (when your classes directly depend on some classes/interfaces from this framework), and use annotations for this purpose. We will return to this point later. But it is important to understand that Spring is just a set of some classes and interfaces that have already been written for you :) I also want to immediately note that Spring can be used not only for web applications, but also for the most common console applications that are so familiar to all of us programs And today we will even write something like that.

Structure

But Spring is not one specific framework. This is rather a general name for a number of small frameworks, each of which does some kind of different job. As you can see, the spring has a modular structure. This allows us to connect only those modules that we need for our application and not connect those that we obviously will not use. As far as I know, it was this approach that helped Spring surpass its competitor at that time (EJB) and take the lead. Because applications using EJB pulled a lot of dependencies with them, and in general they turned out to be slow and clumsy. The image shows that the spring framework consists of several modules:

• data access;
• web;
• core;
• and others.

Today we will get acquainted with some concepts of the main module, such as: beans, context and others. As you might guess, the data access module contains tools for working with data (mainly databases), web - for working on the network (including for creating web applications, which will be discussed later). In addition, there is also the so-called whole Spring infrastructure: many other projects that are not officially included in the framework itself, but are seamlessly integrated into your Spring project (for example, the same spring security for working with user authorization on the site, which, I hope, we will also feel someday).

Why Spring in Java?

Well, besides the fact that it’s fashionable, stylish, and youthful, I can immediately say that as soon as you master it even a little, you’ll understand how much different work you now don’t have to do, and how much Spring takes on. You can write a couple of dozen lines of configs, write a couple of classes - and you will get a working project. But as soon as you start to think about how much is there “under the hood”, how much work is being done, and how much code would have to be written if you did the same project on bare servlets or on sockets and pure Java - your hair stands on end :) There is even such an expression, like the "magic" of Spring. This is when you see that everything is working, but you roughly estimate how much must happen there for everything to work and how it all works there - then it seems that all this is happening thanks to some kind of magic really)) It’s easier to call it all magic than try to explain how it is all interconnected there. smile data_ web-mvc_ security_ just the basics.

DI/IoC

If you tried to read something on Spring, then the first thing you came across was probably these letters: DI/IoC . Now I highly recommend that you take a break from this article and read this article on Habré ! IoC (Inversion of Control) - inversion of control. I already mentioned this in passing when I wrote that when using a library, you yourself write in your code which method of which object to call, and in the case of frameworks, most often the framework will call the code that you wrote at the right moment. That is, here you no longer control the process of executing the code/program, but the framework does it for you. You transferred control to him (inversion of control). DI is understood as either Dependency Inversion (dependency inversion, that is, attempts not to make hard connections between your modules/classes, where one class is directly tied to another), or Dependency Injection (dependency injection, this is when cat objects are not created by you in the main and then you pass them to your methods, and Spring creates them for you, and you just tell him something like “I want to get a cat here” and he passes it to you in your method). We will more often encounter the second in further articles.

Beans and context

One of the key concepts in spring is bean . In essence, it is just an object of some class. Let's say for our program we need to use 3 objects: a cat, a dog and a parrot. And we have a bunch of classes with a bunch of methods, where sometimes we need a cat for a method, and a dog for another method, and sometimes we will have methods where we need a cat and a parrot (for example, a method for feeding a cat, hehe), and in some methods, all three objects will be needed. Yes, we can first create these three objects in the main, and then pass them to our classes, and from within the classes to the methods we need... And so on throughout the program. And if we also imagine that periodically we want to change the list of accepted parameters for our methods (well, we decided to rewrite something or add functionality) - then we will have to make quite a lot of edits to the code if we need to change something. Now, what if we imagine that we have not 3, but 300 such objects? An alternative is to collect all of our such objects into one common list of objects ( List<Object> ) and pass it to all methods, and from inside the methods get this or that object that we need. But what if we imagine that as the program progresses, some object may be added to this list, or (what’s worse) deleted? Then in all the methods where we retrieve objects from the list by their index, everything can break. Then we decide to store not a list, but a map, where the key will be the name of the object we need, and the value will be the object itself, and then we can get the objects we need from it simply by their name: get("parrot") and in response we received an object parrot Or, for example, the key is the class of the object, and the value is the object itself, then we can no longer indicate the name of the object, but simply the class of the object we need, which is also convenient. Or even write some kind of wrapper over the map, where you can make methods so that in some cases you can retrieve objects by their name, and in other cases by class. This is what we get from the spring application context . A context is a set of beans (objects). Turning to the context, we can get the bean (object) we need by its name, for example, or by its type, or something else. In addition, we can ask Spring to go look for the bean we need in its context and pass it to our method. For example, if we had a method like this:

public void doSomething(Cat cat) {
    ...
}

When Spring called this method for us, it passed the object of our cat from its context into it. Now we decide that our method, in addition to a cat, also needs a parrot. Using spring - nothing is easier for us! We simply write:

public void doSomething(Cat cat, Parrot parrot) {
    ...
}

and Spring, when it calls this method of ours, will understand that we need to pass a cat and a parrot here, go to its context, get these two objects and pass them to our method. By handing over the reins of our program to Spring, we also transferred to him the responsibility for creating objects and passing them to our methods, which he will call. The question arises: how will Spring know which objects (bins) to create?

Application Configuration Methods

There are three main ways to configure an application (that is, tell Spring which objects we need to work):

1. using xml files/configs;
2. using java configs;
3. automatic configuration.

Spring developers arrange them in this order of priority:

• the most priority method that should be given preference is automatic configuration;
• if using automatic configuration it is not possible to correctly configure all possible beans, use Java configuration (creating objects using Java code);
• Well, the lowest priority way is the old fashioned way, using xml configs.

In addition, Spring allows you to combine these methods. For example, let Spring do everything that can be configured automatically; where you need to specify some special parameters, do it using Java configs, and in addition, you can connect some legacy configs in xml format. In general, all this can be done quite flexibly. But still, if everything can be done using automatic settings, use it. I will only consider automatic configuration and Java configs; xml configs are already used in almost every Spring example on the Internet, and once you understand how the Java configuration works, there should be no problem “reading” an xml file that does the same thing. Automatic configuration is used when the objects we need for work are objects of classes we have written . If some very specific logic is needed to create an object of our class, or if we do not have the opportunity to mark a class with the annotation we need, which would be picked up by the automatic configuration, this can be done in Java configs. In the next part we will create a maven project, connect a couple of central spring modules to it and create our first beans.