Where should @Service annotation be kept? Interfac

Question

I'm developing an application using Spring. I'm required to use the @Service annotation. I have ServiceI and ServiceImpl such that ServiceImpl implements ServiceI. I'm confused here as to where should I keep the @Service annotation.

Should I annotate the interface or the implementation with @Service? What are the differences between these two approaches?

Answer 1

There are 5 annotations which could be used for making spring beans. List in below of answers.

Do you really need an interface? If you are going to have one implementation for each service interface, just avoid it, use only class. Of course, if you don't have RMI or when interface proxy is required.

@Repository - use for injecting your dao layer classes.

@Service - use for injecting your service layer classes. In service layer also you might need to use @Transactional annotation for db transaction management.

@Controller - use for your frontend layer controllers, such as JSF managed beans injecting as spring beans.

@RestController - use for spring rest controllers, this would help you to avoid every time to put @ResponseBody and @RequestBody annotations in your rest methods.

@Component - use it in any other case when you need to Inject spring bean which is not controller, service, or dao class

Answer 2

I would put @Service on your class but put the name of the interface as a parameter to the annotation e.g.

interface ServiceOne {}

@Service("ServiceOne") class ServiceOneImpl implements ServiceOne{}

By doing that you get all the benefits and can still inject the interface but get the class

@Autowired private ServiceOne serviceOne;

So your interface is not tied to spring framework and you can change the class at any time and not have to update all your injection points.

So if I wanted to change the implementation class I could just annotate the new class and remove from the first but that's all that is required to be changed if you inject the class you could have a lot of work when ever you want to change the impl class

Answer 3

One benefit of spring is to easily switch Service (or other) implementation. For this, you need to annotate on the interface and declare variable like this :

@Autowired
private MyInterface myVariable;

and not :

@Autowired
private MyClassImplementationWhichImplementsMyInterface myVariable;

Like the first case, you can activate which implementation to inject from the moment it is unique (only one class implements the interface). In the second case, you need to refactor all your code (the new class implementation has another name). As a consequence, the annotation needs to be on the interface as much as possible. Furthermore, JDK proxies are well suited for this : they are created and instantiated at application startup because runtime type is known by advance, contrary to CGlib proxies.

Answer 4

Basically annotations like @Service, @Repository, @Component, etc. they all serve the same purpose:

auto-detection when using annotation-based configuration and classpath scanning.

From my experience I am always using @Service annotation on the interfaces or abstract classes and annotations like @Component and @Repository for their implementation. @Component annotation I am using on those classes which serves basic purposes, simple Spring beans, nothing more. @Repository annotation I am using in the DAO layer, for e.g. if I have to communicate to the database, have some transactions, etc.

So I would suggest to annotate your interface with the @Service and other layers depending on the functionality.

Answer 5

I used @Component, @Service, @Controller and @Repository annotations only on the implementation classes and not on the interface. But @Autowired annotation with Interfaces still worked for me.

Answer 6

To put it simply:

@Service is a Stereotype annotation for the service layer.

@Repos­itory is a Stereotype annotation for the persis­tence layer.

@Component is a generic stereotype annotation used to tell Spring to create an instance of the object in the Appl­ication Context. It's possible to define any name for the instance, the default is the class name as camel case.