Spring MVC Project Structure

Whether you like it or not, Spring MVC is by far the the most popular and used web framework for Java. It is important to recognize this popularity and its reputation. It’s one of the most favored framework by federal agencies because the fact that it is Java-based means “enterprise-ready” and that carries a lot of value. It’s an implication of stability, reliability, and support. This blog will attempt to help new Spring MVC developers by presenting a sensible project structure for the framework.

But if you really look at a typical Spring project at work, you will find little standardization that you find in more opinionated frameworks like Ruby on Rails or Laravel (read: Convention over configuration). Spring projects may have a particular front-end templating system, whether it uses JSP or something more JavaScript-powered like angular.js or react.js with pure html files (or some mixture of those products). In addition, Spring is well-known for being supported by many different build tools, such as Maven, Gradle, or Ant.

To make matters even more complicated, the actual structure of the application is different for each project. In general, there’s a package for controllers, models, exceptions, utilities, and exceptions, but some projects might be missing some of these or have a lot more than those.

The problem is the lack of proper initial scaffolding. If you ask a Rails developer to create a “hello world” app and commit it to a remote repository, he can do that in about 5 commands. When he first does “rails new HelloWorldApp”, he (and his team) has a complete understanding of where to locate configurations, source code, and assets. And if you want to add some sorely-needed features such as SMTP or database configurations, there are default values and commented out versions and this leads to faster product delivery in general. It’s no wonder that a lot of startups opt for Rails for this reason.

Take a look at Spring. Unless you’re using Spring Boot, there’s no easy way to guarantee a “properly” setup project structure for Spring. You could rely on Maven archetypes or other alternatives, but in the end, there’s really no official scaffolding mechanism for Spring MVC. It’s all up to you to figure out how to properly set up the classpath, the beans, the properties, and web.xml (or Java configurations).

What I have here is a relatively organized project structure we used for one of the projects:

The source code packages are organized as:
1. Configurations: This will house all the Spring configurations in Java-annotated form
2. Core: Here we store all the Spring Initializer classes
3. Exception: Various business-logic-driven exception classes
4. Model: Data-driven models
5. Repository: Repository classes for data-access, which is powered by Spring JPA
6. Service: All the business logic and authorizations happen here
7. Util: Extra utility classes for SMTP and notifications
8. Controller.API: Controllers for web service endpoints
9. Controller.View: Controllers for frontend view endpoints

These are the essential parts of the application and as you can see, there is no XML configurations involved here. Everything is Java annotation driven, which keeps the code base clean and organized. And the rest are test classes for the source code classes of the same name. There are a couple advantages to doing it this way: 1. It respects the Spring MVC-recommended annotations and organizes the files with that (such as controllers annotating @Controller and repositories annotating @Repository), and 2. In general, it’s easier for developers of other web frameworks to quickly understand the organization because the division of structure closely follows the application layers.

I hope this helps you launch your new Spring project quickly!

If your organization requires a major refactoring of Spring projects or some guidance, please feel free to contact us. Our team of industry-leading experts will make sure that the delivery goals are met from start to finish.