Spring Basics- Coding Standards and Best Practices – Part 1

This Article will illustrate the spring boot folder structures and some of the basic coding standards which we should follw which doing the development in Industrial Level.

1) Project Structure of Spring:

It is always recommended to follow the below package structure while creating a spring based project
• src/main/java – Contains Java Source code packages and classes
• src/main/resources – Contains NON-Java Resources, such as property files and Spring configuration
• src/test/java – Contains Test Source code packages and classes
• src/test/resources – Contains NON-Java Resources, such as property files and Spring configuration

Image title
Image title

2) Project Dependency Standards:

• DO NOT put version numbers below the <properties/> section, this will make it easier to upgrade and test newer versions.
• DO include version numbers for ALL plugins! Do not rely on Maven’s built in Super Pom plugin versions!
• Prohibit the direct or indirect inclusion of incompatible and/or legacy jars. For example, SLF4J 1.5 and SLF4J 1.6 do not work together, therefore we need to prohibit the project from building with mixed dependency versions.

3)Logging Rules:

• NEVER use System.out
• NEVER use System.err
• ALWAYS use Logback
• Prohibit Apache Commons Logging (JCL) aka Jakarta Commons Logging
• Prohibit Java Util Logging (JUL)

4) Configuration Files :

• Config Directories :- src/main/resources/META-INF/spring – Spring XML configuration directory
• Be consistent with naming Spring xml configuration files. Give common prefixes or suffixes to Spring bean configuration files Start all files with the same name such as applicationConfig*.xml.
• Place Spring bean configuration files under a folder instead of root folder.
• Always use a single XML config file to bootstrap the application or tests
• Use the XML “id” attribute to identify a bean
• Use Constructor injection to promote thread safety
• Avoid using import elements within Spring XML configuration files as much as possible. either prefer loading xml configuration files by making use of wild cards or create a separate xml configuration file, whose sole purpose is just to contain elements.

<import resource="classpath:/appcontext/beans-controller.xml"/>
<import resource="classpath:/appcontext/beans-service.xml"/>
<import resource="classpath:/appcontext/beans-dao.xml"/>

• Stay away from auto wiring in XML based bean configurations. make use of auto wiring in all of your bean definitions throughout the application
• Instead of placing hard coded values in bean definitions, place property placeholder variables in place of actual values. it will be easier to customize system configuration according to the target runtime environment without requiring any modifications in the bean configurations.

<property name="driverClassName"value="${dataSource.driverClassName}"/>
<property name="url" value="${dataSource.url}"/>
<property name="username" value="${dataSource.username}"/>
<property name="password" value="${dataSource.password}"/>

• place your resources somewhere under classpath and place classpath: prefix in front of their paths.

<context:property-placeholder location=”classpath:application.properties”/>

5) Application Layer:

Application components (beans) should be separated into distinct layers, and categories.
Bean Layers
1. Controllers (for MVC, System Domain)
2. Services (Problem Domain)
3. Repository (System Domain)
Other Bean Categories
• Data Transfer Objects (Problem Domain)
• System Functions (System Domain)
It is always advided to use Annotation driven bean configuration
Controller Beans:- the simplest way for creating a controller class to handle one or multiple requests is just by annotating a class with the @Controller

public class HomeController {
private UserDAO userDAO;
@RequestMapping(value = "/visit" method = RequestMethod.POST)
public String visitHome(@RequestParam String username,
@RequestParam String password) {
// do something before returning view name
return "home";

@RequestMapping annotation is used for specifying URL mapping(requests) and the request type GET/POST
Retrieve request parameters as regular parameters of the handler method by using the @RequestParam annotation
After business logic is processed, a handler method should return a view which is then resolved by the Spring’s dispatcher servlet. Spring allows us to return either a String or a ModelAndView object from the hander method.
Use the @Autowired annotation to let Spring automatically injects actual implementation of a business class to the controller

Service Beans:- Service Beans are Problem Domain components. These are the MOST significant in the application. Service beans are the Fundamental component of SOA.
• These are POJOs
• Always defined from interfaces
• NEVER include infrastructure components
• NO import of Spring or utility libraries
• NO infrastructure annotations
• Always declare transaction boundaries by public functions
• Create implementation/concrete classes in a sub-package named internal.
• Prefer throwing runtime exceptions instead of checked exceptions from service layer
Spring annotations can be very useful for services, useful annotations are @Service and @Transactional. To abstract away the infrastructure from the business services, create a project specific meta annotation.

Repository Beans:- Repository beans are in the System Domain.
• DO NOT contain business logic
• Do use Spring and JPA annotations
• Should be considered disposable.
• Manage transactions only in the dao layer
• Mark transactions as readOnly=true when methods only contain queries
• Use SessionFactory and EntityManager directly in your DAO beans

Data Transfer Beans:- Data Transfer Objects (DTO) are the fundamental objects in and out of our system. DTOs are simple public POJOs that receive and send data as a logical set.
• Always Public Beans
• Annotate with JAXB2 Annotations

Bean Naming:- The Spring Context is the container for the application’s beans. Each bean is uniquely identified by its name. The XML attribute “id” is most commonly used to define the bean’s name.

<bean id=”accountService” class=”com.gordondickens.services.AccountService/>

In the next post, we will look into the some more practices and spring coding standards.

Be the first to comment

Leave a Reply

Your email address will not be published.