@Repository, @Service , @Controller and @Component identify classes as beans
Since spring version 2.0, some annotations have been introduced to simplify the development of Spring. The @Repository annotation is one of the first to be introduced and is used to identify classes in the data access layer (DAO layer) as Spring Beans. Specifically, just mark the annotation on the DAO class. At the same time, in order for Spring to scan the classes in the classpath and recognize the @Repository annotation, it is necessary to enable the automatic scanning of beans in the XML configuration file, which can be achieved by <context:component-scan/>. As follows:
// First declare the DAO class as a Bean using @Repository
package bookstore.dao;
@Repository
public class UserDaoImpl implements UserDao{ …… }
// Second, start Spring's auto-scanning feature in the XML configuration file
<beans … >
……
<context:component-scan base-package=”bookstore.dao” />
……
</beans> |
In this way, we no longer need to explicitly use <bean/> in XML for bean configuration. Spring will automatically scan all class files under the package specified by base-package and its subpackages when the container is initialized, and all classes marked with @Repository will be registered as Spring Beans.
Why @Repository can only be marked on DAO classes? This is because the function of this annotation is not only to identify the class as a bean, but also to encapsulate the data access exception thrown in the marked class as Spring's data access exception type. Spring itself provides a rich data access exception structure that is independent of specific data access technologies, which is used to encapsulate exceptions thrown by different persistence layer frameworks, making exceptions independent of the underlying framework.
Spring 2.5 adds three additional annotations with similar functions on the basis of @Repository: @Component, @Service, @Constroller, which are used at different levels of the software system:
- @Component is a generalized concept that only represents a component (Bean), which can act at any level.
- @Service usually works at the business layer, but currently the functionality is the same as @Component.
- @Constroller usually acts on the control layer, but currently the functionality is the same as @Component.
By annotating the class with @Repository, @Component, @Service and @Constroller, Spring will automatically create the corresponding BeanDefinition object and register it with the ApplicationContext. These classes become Spring managed components. These three annotations remove classes that act on different software levels, and are used in exactly the same way as @Repository.
In addition, in addition to the above four annotations, users can create custom annotations, and then annotate @Component on the annotation, then the custom annotation will have the same function as the @Component. However, this feature is not commonly used.
When a bean is detected automatically, its bean name is generated according to that scanner's BeanNameGenerator strategy. By default, for @Component, @Repository, @Service, and @Controller that contain a name attribute, the value of name is used as the bean's name. If this annotation does not contain a name value or other component found by the custom filter, the default bean name will be the unqualified class name starting with lowercase. If you don't want to use the default bean naming strategy, you can provide a custom naming strategy. First implement the BeanNameGenerator interface and confirm that a default parameterless constructor is included. Then provide a fully qualified class name when configuring the scanner as follows:
<beans ...>
<context:component-scan
base-package="a.b" name-generator="a.SimpleNameGenerator"/>
</beans> |
Like the Spring Bean configured through XML, the default scope of the bean identified by the above annotation is "singleton". In order to cooperate with these four annotations, the scope of the bean can be specified while marking the bean. Spring 2.5 introduced @ Scope annotation. Just provide the name of the scope when using this annotation, like this:
@Scope("prototype")
@Repository
public class Demo { … } |
If you want to provide a custom scope resolution strategy without using annotation-based methods, simply implement the ScopeMetadataResolver interface, making sure to include a default no-argument constructor. Then provide the fully qualified class name when configuring the scanner:
<context:component-scan base-package="a.b" scope-resolver="footmark.SimpleScopeResolver" />