XML or @nnotations in Spring Framework? This is the dilemma
By: Marco Domenico Marino
Tags: Software Development, Spring, Developer, Software Engineering, Java

Definition of beans by XML

In our project we need to edit the web.xml file to include the Spring servlet:

Definition of the web.xml for xml configuration

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:

Bean definition file beans.xml

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.

Example of root file to define 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.

: 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.

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.

Logical representation of the bean structure and of the xml configuration files

These are the most common grouping way, but there are many other classification depends on the structure and the philosophy of the architecture.