What is the point of autowiring a repository in Spring Boot when you can define it as a parameter in the method definition?

Often in certain types of applications (notably web apps) we’d want to define a bunch of elaborately-configured objects that we’d then potentially want to use in multiple places.

Singletons could be used to do this, and autowiring is an alternative to that. By defining concepts like “controllers” and “repositories” in standard structured ways (often either via annotations or else XML), Spring MVC nudges us towards a clear standard structure and autowiring makes it much easier to spot where the equivalent of singletons are being used.

If you want to Gain In-depth Knowledge on Spring Boot, please go through this link Spring Boot Training

A web or database app can then execute in a “context”, in which there are certain clearly-defined singletons (“beans” with the default singleton scope), and we can use those in locations that are easy to spot, without getting into a lot of messy parameter passing or arbitrary use of singletons.

Passing things around as parameters alone would be tricky in a web app, because controllers or their equivalent are invoked by requests that originate with web browsers or software using web services, rather than being evoked by our own programs.

This is partly why Spring is particularly popular in web apps; they are event-driven and typically make use of multiple elaborately-configured singletons, which we cannot easily pass around as parameters and which would be messy to work with as singletons. Among other things, instead of ending up with code like BookRepository bookRepo = BookRepository.getInstance(); or BookService bookService = BookService.getInstance();, sprinkled throughout some class that responds to web requests, we simply have

@AutowiredBookService bookService;

as an instance variable of the class or classes that need to use the service. Then you can just use the bookService variable where you need it in that class. If you delete the autowired variable definition, it becomes immediately obvious where you’ve used the variable.

A bit of a downside with Spring used to be that beans were defined in XML, which is verbose in itself, but now that we can use annotations and Java config to define beans, XML is rarely needed. You can use it if you like it, and not use it if you don’t.

Take your career to new heights of success with an Spring Boot Course

Spring does not do injection via method in the strict sense of the word, except the context declaring a method as bean providers using the @Bean annotation:

What is important to understand how Spring process a given configuration, and how it handles injections. Given the following mock (kotlin) sample configuration:

Spring process injection requests roughly in the following manner (order my be different):

1. First it attempts to find bean which is a an audit logger, if it cannot find one the whole Reporting Module Configuration would fail with an exception.
2. It also tries to find the dependency for the scheduler client (line 5), again if none could be found, the configuration of the container is aborted with an exception.
3. Next it tries to find a Report Repository in the container, required to create the reporting service via the repotingService function.
4. Spring the invokes the function to provide an Reporting Service bean.

In any case what spring can do with field injection is that can replace, in the above sample configuration with a proxy which allows it to delay the construction of the dependency until it required by the configuration, or by the application accessing the bean, e.g lazy/on demand.

By doing constructor injection, the configuration enforces the availability of an dependency as soos as possible, which is most of the time the best thing to do for the following reasons:

1. It prevents cyclic dependencies.
2. It requires less, or sometimes none at all, of the magic of wrapping via proxies, which does speed up startup time.
3. It forms a clear dependency tree at startup, which does it make easier to reason when things stop working.
4. It is much more pure way of constructing something, as passing the constructor means the component is fully configured.

But there are also situations where field injection can be a boon:

1. It can actually be used as tool to break cyclic dependencies by delaying allowing the spring startup to re-order services to avoid dependencies.
2. It can give the component in question more control over its construction, via life cycle method annotated by , for example the @PostConstruct annotation.

To get in-depth knowledge on Spring Boot, enroll for live free demo on Spring Boot Online Training