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