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

Many people, after reading my articles about creating a blank for a web project and about creating a simple web service on servlets , were interested in when I would write about Spring. I didn’t want to, I offered to read 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 and wrote an article once, and then just threw a link to it. So I'm writing for reference)). In this article, I will not write how to make a working project in spring in 5 minutes according to my example. I will write only about the basic things, without the knowledge of which it is certainly possible to “cut down” the project, but what happens there, and, more importantly, why, it will not be clear.

What is Spring Framework?

Spring Framework , or simply Spring , is one of the most popular frameworks for building Java web applications. framework- this is something similar to a library (perhaps this term is more familiar to you), but there is one point. Roughly speaking, using the library, you simply create objects of the classes that it contains, call the methods you need, and thus get the result you need. That is, there is a more imperative approach here: you clearly indicate in your program at what specific moment it is necessary to create which object, at what moment to call a specific method, and so on. With frameworks, things are a little different. You just write some of your 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 getting 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 rigid coupling to the maximum (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's important to understand thatspring is just a set of some classes and interfaces that are already written for you :) I also want to note right away that spring can be used not only for web applications, but also for the most common console programs so familiar to all of us. And today we will even write something like that.

Structure

But Spring is not one specific framework. It is rather a generic name for a number of small frameworks, each of which performs some kind of work. As you can see, the spring has a modular structure. This allows you 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 to bypass its competitor at that time (EJB) and take the lead. Because applications using EJBs pulled a lot of dependencies behind them, and in general they turned out to be slow and clumsy. The image shows that the spring framework consists, as it were, 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 somehow).

Why Spring in Java?

Well, besides the fact that it is fashionable-stylish-youth, I can immediately say that as soon as you master it at least a little, you will understand how much different work you don’t have to do now, and how much Spring takes on. You can write a couple of dozen lines of configs, write a couple of classes - and you get a working project. But as soon as you start to think about how much everything is "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 everything needs to happen in order for everything to work and how it all works there - it seems that it all happens thanks to some kind of magic really)) It's easier to call it all magic than to try to explain how everything is interconnected there. :) Well, the second argument "for" studying Spring is that in about 90% of vacancies for a junior (according to my personal observations) - either knowledge or at least a general idea of ​​\u200b\u200ba gentleman's set of spring fromdata, web-mvcand security:) But today only about the basics.

DI/IOC

If you tried to read something in the spring, then the first thing you came across was probably these letters: DI / IoC . Now I highly recommend you to digress 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 time. That is, here you no longer control the process of executing the code / program, but the framework does it for you. You gave it control (inversion of control). DI is understood as Dependency Inversion(dependency inversion, that is, attempts not to make hard links between your modules / classes, where one class is directly tied to another), then Dependency Injection (dependency injection, this is when you do not create cat objects in main and then pass them to your methods, and the spring creates them for you, and you just tell him something like "I want to get a cat here" and he passes it to your method). We will often encounter the latter in future articles.

Beans and context

One of the key concepts in spring is the bean . Basically it's just an object .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 a cat and a parrot are needed (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 main, and then pass them to our classes, and from inside the classes to the methods we need ... And so on throughout the program. And if we also imagine that from time to time 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 do quite a lot of code changes if we need to change something. And now if we imagine that we do not have 3 such objects, and 300? As an option, it is to collect all our such objects into some one common list of objects (List<Object> ) and pass it to all methods, and from within the methods we can already get one or another object that we need. But what if we imagine that in the course of the program some object can be added to this list, or (worse) removed? Then in all methods where we get objects from the list by their index, everything can break. Then we decide to store not a list, but a map, where the key is the name of the object we need, and the value is the object itself, and then we can get the objects we need from it simply by their name: get("parrot" )and received a parrot object in response. Or, for example, the key is the class of the object, and the value is the object itself, then we can no longer specify 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 to make methods to get objects by their name in some cases, and by class in other cases. This is what we get the application context from the spring. Context is a set of beans (objects). Referring 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 the spring itself to go look in its context for the bean we need and pass it to our method. For example, if we had a method like this:

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

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

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

and spring, when it calls this our method, it will understand that it is necessary to pass a cat and a parrot here, it goes into its context, gets these two objects and passes them to our method. By transferring the reins of control of our program to Spring, we also shifted the responsibility for creating objects and passing them to our methods that it will call on it. The question arises: how will spring know which objects (beans) to create?

Application Configuration Methods

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

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

Spring developers rank 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 the 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, everything that can be configured automatically - let the spring do it itself, 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 configuration, use it. I will only consider autoconfiguration and java configs; xml configs are already used in almost every spring example on the Internet, and having understood how the java configuration works, there should be no problems in order to "read" the xml file that does the same. Automatic configuration is used when the objects we need for work are objects written by usclasses. If some very specific logic is needed to create an object of our class, or if we do not have the opportunity to mark some class with the annotation we need, which would be picked up by 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.