Controller belongs to the Presentation layer?

The presentation layer contains views and controllers.
You must not mistake an MVC architecture for a multitier/layer architecture (especially a 3-tier architecture). Most of the time Model/View/Controller is not the primary design of a web application, it is just a subset of a multitier/layer architecture.

Take a look at this oversimplified scheme (you could have the DAOs in a dedicated Data Access Layer, but this is not important in this post) :

Spring MVC is a presentation framework : it deals with controllers and views. But why the "M" in Spring MVC ? Just because, as many other presentation framework, it naturally deals with a representation of a model/entity ("M"). This representation is the one used in your controllers, displayed in your views, submitted in your forms, etc. That's why the framework is called Spring MVC, even if the model/entity is not part of the prensentation layer.

I think it is a good name for this Framework, because it is really "MVC" oriented. Indeed the representation of a model/entity can be :

• direct : the framework directly handles the model/entity object
• indirect : the framework handles a form object or DTO, that contains information related to one or multiple entities

Spring's recommendation is to directly use the model/entity ("M") object :

Reusable business code, no need for duplication. Use existing business objects as command or form objects instead of mirroring them to extend a particular framework base class.

That's why I say the framework is very "MVC" oriented, compared to others, like Struts, where you have to use different form objects.

Some interesting links :

• Comparison between Multitier and MVC architecture, from Wikipedia
• This blog post about 3-tier architecture in ASP.NET
• This blog image of a 3-tier architecture
• DispatcherServlet chapter from Spring's documentation

It largely depends on what flavor of MVC you're using, and what environment you're using it in.

For example, ASP.NET MVC is entirely a UI pattern, so all three parts are part of presentation.

However, in most implementations of MVC, the Controller interacts with the user, and thus is part of the UI layer. It may handle button presses, and keyboard input... but in many cases, the controller is also responsible for connecting the Model and the View together.

The one universal truth is that you should NOT be doing business logic in the controller if you cannot help it. Where the business logic exists depends on many factors. It might be part of the model in some implementations, or it may be it's own separate layer outside of MVC

The controller controls the presentation layer logic. For all the business code, transactional use cases, persistence, etc., it typically delegates to a service layer.

A typical way of doing that is to implement transactional services as spring beans and inject those spring beans in controllers. Typical use case: create a new product:

1. The controller receives a command bean from the browser
2. It validates that all the required data is present, and if not, redisplays the product creation page with error messages
3. It calls a service bean to create the product
4. The service bean runs in a transaction. It gets the product category from the database, attaches the product to its category, computes the price for the product based on current pricing strategies, sends a JMS message to an external application, and returns the ID of the created product
5. The controller redirects to the product detail page, using the ID of the created product as a URL parameter.