As the majority of modern frameworks, Spring 3 allows one to declare its components (Spring Beans) via annotations, making XML unnecessary. However, it can cause some confusion about the different annotations available that apparently do the same thing.

Defining where Spring should look for annotations

When we add an annotation to some class, we are putting a meta-information, that is, an arbitrary information that has nothing to do the code or the properties of the class, like its name, modifiers, etc.

However, Spring (as any other framework) needs to find and read annotated classes in order they can effectively be used.

This is done through XML configuration:

<context:component-scan 
    base-package="com.package.project.service,
                  com.package.project.controller"/>

Also through the annotation @ComponentScan:

@Configuration
@ComponentScan({
    "com.package.project.service",
    "com.package.project.controller"})
public class SpringConfiguration { ... }

In the above example, we defined in which packages Spring should search for classes. It’ll look for classes with component annotations in these packages and in their subpackages.

Grouping components with stereotypes

Firstly, there is the generic @Component. This annotation makes one class a bean available for dependency injection to the remaining components of the system.

On the other hand, there are more specific annotations that allow us to mark beans with stereotypes, as in UML. This way, the components can be grouped by their “type” or behavior.

If one class is annotated with @Service you can just suppose it contains business methods, high level transactions or some logic related to the application model.

The annotation @Repository makes it obvious that the component implements Repository design patter (which is not the same of DAO, even though they are somehow analogous).

Finally, the annotation @Controller associates a component with a MVC controller.

The benefits

At first it looks like frills, but actually there are a few advantages:

It helps separating the logical layers of the application.
It enables Aspect Oriented Programming (AOP), like Spring Data JPA module, which dynamically “implements” interfaces annotated with @Repository.
It allows you treat separately exceptions that are specific of a layer, using again the example of data access layer (@Repository), where Spring will translate specific database driver exceptions into standardized classes.
You can also create any new feature specific to a layer. Just use your imagination and creativity. 😉

Considerations

The performance of “component-scan” is my main reservation about annotations as a new standard against the traditional and verbose XMLs. If we configure a broad package, that is, containing many classes, it can slows down the application startup, since Spring will take some time to list all classes and check them for annotations. Maybe mapping your beans with XML will be better if startup time is an important requirement for you.