Where to put business logic in spring mvc framework?

Question

I don't know where to put the business logic in spring mvc because I'm new to it. I have a clue on what to do but because of lack in knowledge in spring mvc, I don't know where to start. I would also like to ask if somebody knows where I can get a good tutorial on this or a complete sample of a spring mvc web application that has a business logic on it? Anyways, the business logic that I was talking about is all about database handling :)

Answer 1

@Controller classes serve as C from MVC. Note that the real controller in Spring MVC is DispatcherServlet that will use the specific @Controller class to handle the URL request.

@Service classes should serve for your service layer. Here you should put your business logic.

@Repository classes should serve for your data access layer. Here you should put CRUD logic: insert, update, delete, select.

@Service, @Repository and your entity classes will be M from MVC. JSP and other view technologies(e.g. JSP, Thymeleaf etc.) will conform V from MVC.

@Controller classes should only have access to @Service classes through interfaces. Similar, @Service classes should only have access to other @Service classes and for a specific set of @Repository classes through interfaces.

Answer 2

Many people would recommend to add the business logic to the service layer. I personally find out that's not a great idea, specially when you start testing: you may have to deal either with the persistence and business logic at the same time, or mocking everything around, and then things can get very messy.

I do recommend reading this article before taking any conclusions: The Biggest Flaw of Spring Web Applications

Resuming, the idea would be to move the business logic to the model layer and simplify your services methods.

Answer 3

Generally, your business logic goes in the service layer. Though you can put basic validation rules in your pojos with JSR annotations.

For a Spring MVC app you have controllers, which handle http requests, and a domain layer, which are pojos representing your business models. You often have a persistence layer, or DAO. You might have a service layer as well, for helping with non-trivial logic.

Your comment about database handling doesn't make sense. Business rules are orthogonal to storing data. Your database handling should go in your persistence layer.