XML or @nnotations in Spring Framework? This is the dilemma
How to choose the best beans configuration in a Spring project
Intro
When you start to work on a new Java Web project and your client tells you “please, use the Spring Framework…” in your mind starts the circus…
….. dancing monkeys that uses @nnotation to define the Beans or trained lions that indents the configurations of the beans on the right XML file…
In this story I’ll try to describe the two ways to define Bean of the Spring context, rather XML config and @nnotation, and for every way I will try to explain to you my opinions.
First of all, we need to have a Java EE Web Project, with Maven and Spring Framework included…
Let’s go!
Definition of beans by XML
In our project we need to edit the web.xml file to include the Spring servlet:
The Spring servlet intercepts request and response that the Dispatcher manages to operate it in the Spring Context. The Spring Context contains and manages the lifecycle of the Spring Beans.
After the introduction of the servlet we need to create a root XML file that is used by the servlet to start the Spring Context:
Into this file we can include all the beans that we intend to use in our Web application.
The Spring Framework permits the import of different bean XML config file into a parent file: it is so possible to create an organized structure of this file, and indirectly of the beans.
There are many ways to organize the configuration files depends on the architecture of the web application, for example the beans can be grouped for:
- Scope: as we know the Spring beans can be configured to have different lifecycle independence of their scope (singleton, prototype, session, etc.). If the Beans are proportionally divisible by their scope and the architecture prefers a vision scope-centric (the beans are easily identifiable by their scope an not by their function or use) it is advisable to separate the beans in different XML files divided for the scope. For example we will have a file singleton-bean-definition.xml that will contain all the singleton beans included in the application and in the same way for the other scope.
- Type: in the architectures that implement the pattern MVC on server-side, for example, is required the presence of Model, View and Controller Beans. These are 3 types of different Beans that can habit the Spring context and in this scenario it is possible to divide the XML config file in 3 files everyone that represents the typology of the Bean into the architecture.
- Layer: in a multi-layer architecture, for example a REST services API, you can organize the beans by a logical separation of layers. First of all the beans that represent the entry point of the services, after the beans that includes the business logic and last-but-not-least the bean that include access to external services or to the database.
These are the most common grouping way, but there are many other classification depends on the structure and the philosophy of the architecture.
Definition of beans by @nnotations
If we decide to not use the xml configuration files to organize our project structure it is possible to follow on another way: the class @annotation.
Withe the class @annotation is possible to initialize and configure the Spring Context adding the right annotation attribute directly on top of the Java classes.
First of all we need to create the application config class that represents the root of the Spring Context and add the reference to the web.xml file.
Because the beans not are collected in xml files and are identifiable only by the annotations is needed a configuration class the start the Spring Context and scan all the packages to search the annotated class:
This class is triggered by the web application (referenced in web.xml) and when instantiated start the context, scan the packages and go live to the founded beans.
The beans are so scattered into the project: a developer adds the @annotation on a class if identifies that it must to become a Spring Bean.
Also in this scenario there many ways to organize the classes and/or the packages to try to follow a common guideline, for example you can use these tips:
- Class name suffix: it is useful to add a suffix on the name of the class to implicitly identify the typology of the Bean. For example in a MVC architecture it is possible to name the Bean class as {class}ControllerBean.java, {class}ModelBean.java and {class}ViewBean.java. In this way you can easily identify or search the beans into the project and, from a page, detect the Bean connected to it.
- Name explicit packages: it is also possible to collect the Spring Bean clustering by a package identification. For example in a REST application you name the packages in this way it.mamino84.example.bean.business that includes all the Spring Bean of the layer business independently of their scope.
The use of the annotation to label the Spring Bean is more widespread in web applications especially in architecture that adopts the SpringBoot framework.
It’s time to decide! Xml or @nnotations?
Both configurations are similar and easily exchangeable: is it possible to switch from xml configuration to @nnotation and return, but it is better to make this choice in the design phase of the project.
Every feature available with XML configuration is also available with @nnitations.
XML configuration, in my opinion, is preferable:
- In the context of more rigid architecture because you define the solution at the beginning of the project and in the course every developer need to comply with it
- In the project with 5 or more developer to guarantee a more easy and centralized way to define and config the beans
- In teams and project that uses a more rigid methodology to realize the application (ex.: waterfall) because the definitions of all Beans can be made in the first phase of the project and after you will manage only little updates
@annotation configuration is preferable instead for these situations:
- In cases of flexible architecture thought and realized day-by-day is advisable to use this approach because you can promote a class to Bean in every moment during the develop
- In teams with 5 or less developer because it is necessary to stay together, maybe in the same room, and share the decisions about what class need to became Bean or for example the right scope to assign to the Bean
- In teams that embrace methodology different by waterfall (for example Agile) because the teams necessarily will not have more developers and not impose to get all the decision at the start of the project, but the Spring Context will be made run-by-run
Over these classifications it is possible to have more hybrid scenarios to realize a Spring Web Application.
Thank you for your time!
Reference: Spring Framework Reference Documentation
Follow me on GitHub: XML Project and Annotation Project
