I'm developing a web application for a university project and it has been told to us to use Java EE and to provide documentation. I'm having trouble understanding how to fit the MVC pattern in the multi-tier architecture and how to describe them, since I've found articles on the internet saying different things.
From what I read (expecially about BluePrints at sun.java.com), I should use 4 tiers (client, web, business and data) and the business logic is divided between web and business tiers, isn't it? Then I can use the MVC pattern to organize these two layers:
Am I right?
There are a couple of approaches to MVC in Java EE.
The somewhat older approach (but depending on the context still valid) uses JSP for the view and Servlets for the controller. It's often debated what the model exactly is, but it's typically taken to be Services (represented by e.g. EJB session beans) that return domain entities (represented by e.g. JPA Entities).
In modern versions of Java EE, there's a default MVC framework called JSF. Following this framework, Facelets is used for the view and the controller is given (you don't need to implement it).
There's an in-between concept called the backing bean, which is often referred to as the model, but isn't a pure model itself. Instead, it delegates to the real model (e.g. EJB services). The backing bean can also take up some controller responsibilities (issuing a redirect, or putting a message in a kind of queue for the view to display).
Sometimes it's thought that creating a web and business tier is overkill, but this absolutely doesn't have to be the case. It's often just a matter of applying sound OO principles. The other extreme, e.g. stuffing everything on a JSP (html code, controller logic AND business code) is far, far worse.
See this example of how simple a 3 tier (3 layer actually) Java EE MVC application can be: Minimal 3-tier Java EE app, without any XML config
A related question is this one: What are the main advantages of MVC pattern over the old fashioned 3-layer pattern