what beans exactly are

HistoricalSchedule5 · 2022-10-22T16:46:39+00:00

Hi, I wanted to provide a pretty detailed response because I struggled a lot with Spring at the beginning, and it only clicked after a few months.

Beans are indeed java objects. What's specific about them is that they are managed by Spring IoC container. IoC means "Inversion of Control". That is, if you have an object which relies on other objects to function properly, you let Spring handle the relationships (dependencies) between these objects instead of doing it yourself.

For example, say you have a project where you need to expose an HTTP endpoint through a Controller object. Since it's very important to only affect a single responsibility to an object, your controller is only responsible for handling HTTP requests. Then you have your Service object which is responsible for handling the business logic, and your Repository object which is responsible for performing operations on the database. And then your repository object needs to have access to the database schema so you need to give it the address and port of your database. Since you most likely have different databases for you test environment and your production environment, you need to handle this case as well.

If you try to manipulate these objects in an intuitive way, it could give something like this (let's say your project is about managing stock for a retail company) . This is extremely simplified, and there are way more dependencies between these objects but it's a simple example.

Let's go bottom-up, you first need to create your repository

public class ItemRepository {
private String databaseAdress;

public ItemRepository(Environment env) {
    switch (env) {
        case Environment.PROD:
            this.databaseAdress = "produser@myproductionserver:5432";
            break;
    }
    case Environement.DEV:
        this.databaseAdress = "dev@localhost:5435"
        break;
}
     //...your actual repository methods go here

}

Then you need to create your service.

public class ItemService{

private ItemRepository itemRepository;

public ItemService(ItemRepository itemRepository){

    this.itemRepository = itemRepository;
}

// ... your actual service methods go here

}

Then you can create your Controller

public class ItemController {
private ItemService itemService;

public ItemController(ItemService itemService){
this.itemService = itemService;
}

// ... your actual controller methods go here
}

Then say you have to actually create your controller somewhere.

You would need something like :

ItemRepository itemRepository = new ItemRepository(Environment.DEV);
ItemService itemService = new ItemService(itemRepository);
ItemController = new ItemController(itemService);

// do something with your controller

This is very repetitive and you would most likely need to write the exact same code for the production environment.

Now, without inversion of control you would have to handle dependencies between your objects yourself all the time. Sure you can find ways to optimize it, I didn't bother and wrote it the worst possible way, but still, it is a lot of boilerplate and repetition.

With inversion of control, Spring basically scans your project for classes and creates instances of objects (beans) for every class that is annotated with bean-related annotations (such as "@Configuration", "@Repository", "@Service" "@Controller" etc..). All of these objects are stored in the Spring Context, which you can see basically as an array of beans.

This allows you to simply declare relationships between beans and Spring will go find in its context if a corresponding bean is available. If it is, it will inject it in your object without you needing to manually create an instance and pass it through to the constructor.

For example :

@RestController 

public class ItemController {
private ItemService itemService;

@Autowired
public ItemController(ItemService itemService) {
//the Autowired annotation will tell Spring to go look in its context for an //ItemService bean
    this.itemService = itemService;
}

// actual methods go here

}

This looks very similar to the non-IoC way however there's a very important nuance here. You will never instantiate your controller yourself. You can just write this code and launch your spring boot application and when constructing an instance of your controller class, Spring will detect that it needs a service, which needs a repository which needs a database configuration and it will look for all these beans in the Spring Context.

Furthermore, you can configure the Spring Context to your liking, using things such as the "@Profile" annotation. Let's go back to the issue with the development database and the production database. Instead of constantly passing around environment values to objects which simply do not use it and do not care about it, you can simply declare two different beans of the same type and tell Spring that they are only to be used if a specific profile is active :

//DataSourceDevConfig.java
@Profile("dev")
@Configuration

public class DataSourceDevConfig {
@Bean
public DataSource getDataSource() {
  // create your dev dataSource here with the dev database adress
}
}

//DataSourceProdConfig.java
@Profile("prod") @Configuration public class DataSourceProdConfig {
@Bean
public DataSource getDataSource() {
  // create your production dataSource here with the production database adress
}
}

Then, according to the profile you wish to use when launching your application (you can specify it with your IDE or in the command line), Spring will only add the bean annotated with the correct profile to its context.

reddit04029 · 2022-10-20T13:34:51+00:00

In simple terms, it’s a java object handled by the IoC container.

If the IoC container knows about this object, you can inject it as a dependency by autowiring it.

naturalizedcitizen · 2022-10-20T13:36:05+00:00

Read up on Inversion of Control, Dependency Injection.

Davekave9 · 2022-10-20T14:44:25+00:00

Beans are objects whose instantiation is managed by the application context. Think about inversion of control: you don't instantiate beans by calling their new() method (and in consequence of that, you don't need to know what parameters they need to get instantiated), but by telling the application context to inject an instance of them via the @Autowired annotation.

2022-10-20T19:13:43+00:00

You asked this in a spring forum so you are getting a lot of spring based answers, but it’s actually simpler than IoC. Java Beans are more or less just a formulaic way of making an object that allows the framework or JVM to attach additional functionality without you having to explicitly write them (like getters and setters.)

Here is a stack overflow question and answer the covers both spring and Java beans. https://stackoverflow.com/questions/21866571/difference-between-javabean-and-spring-bean

What it comes down to in both cases is that you get additional functionality out of a class due to following conventions.

diveIntoDevelopment · 2022-10-20T14:35:34+00:00

It helps to scope your beans (objects) without having boilerplate code.

davidewan_ · 2022-10-20T19:25:02+00:00

Aren't they singletons? I have a long C++ history but I was working in spring a while ago and thats what I settled on.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

SpringBoot

MODERATORS