|
|
Posted on 8/30/2018 1:29:41 PM
|
|
|
Today I discussed with my colleagues whether to use a combination of @Configuration and @Bean to create beans in Spring Boot or to use @Service and other annotations directly on the class. The author tends to use the first one, that is, a combination of @Configuration and @Bean.
Let's look at an example first, the goal is to create a bean for the SearchService.
Use @Service directly:
Start the application, browser access: http://localhost:8081/search?q=koly, page display: ["hello", "koly"]
Ways to use @Configuration and @Bean:
Compared to using @Service code directly, there is an AppConfig class that removes the @Service annotations placed on top of ElasticSearchServiceImpl. At a glance, there is more code and classes. So what are the benefits of using the latter?
The author believes that the benefits are:
Separation of concerns
Using @Configuration and @Bean methods, the creation of beans is all in one place, and the interface and its implementation have nothing to do with the creation of the bean.
If the creation of the bean needs to be changed, then you only need to view and modify the corresponding Configuration class, and you do not need to go to the corresponding Java bean to make changes. For example, sometimes bean creation needs to be cooperated with @Scope or @Profile, and only need to modify the Configuration class.
Single duty
@service annotation itself assumes two responsibilities:
One is the creation of beans;
The second is to identify a class as a service.
Indicates that an annotated class is a "Service", originally defined by Domain-Driven
Design (Evans, 2003) as "an operation offered as an interface that stands alone in the model, with no encapsulated state."
Above is Spring's explanation of @Service annotations. That is@Service actually represents a stateless, independent, interface operation in DDD.
In the way of @Bean and @Configuration cooperation, the creation of beans is handed over to a separate class, and the identity of Service is handed over to the interface and class name in Java. This is also reflected in Spring Data, such as Repository, which is identified by name, such as CrudRepository. Therefore, Service is also reflected by the name. Specific hierarchy definitions can be used to provide more layers according to the project by name without relying on the annotations provided by Spring, such as Mapper layer, Validator layer, etc.
In addition, bean and service are two dimensional concepts. One about the concrete implementation and the other about the concepts in DDD.
More flexible
Using @Bean methods, you can create instances of classes in the library. If you use the @Service method, you will not be able to add @Service comments to the corresponding classes in the library.
Least knowledge
The principle of minimum knowledge means:
The less technology or knowledge required to complete the function, the better, so as to ensure the simplicity of the project and reduce the difficulty of learning the project.
Since it is not possible to create instances of classes in the class library using @Service, you have to use the form of @Configuration and @Bean when encountering similar needs. At this point, there are annotations such as @Service, @Configuration, and @Bean in the entire project, and these annotations do the same thing, i.e. create the bean.
With @Service, there is a high probability of @Service, @Component, @Configuration and @Bean at the same time.
while using @Configuration and @Bean can completely eliminate the use of @Service and @Component, which is in line with the principle of minimum knowledge.
Finally, by the way, Spring beans were created in xml and later used Java for configuration. The main reason for not using XML is that it is not concise enough and does not have features such as compile-time checking, rather than the need to spread the creation of beans across classes.
To sum up, the author prefers to use @Configuration and @Bean methods. |
Previous:A simple way to clear the screen from the Python command lineNext:Several ways to use distributed locks (redis, zookeeper, database)
|
