Here's my opinion.
MVC is a architecture
pattern that comes from smalltalk. The major point in mvc is the decoupling amont 3 pieces: controller, view, model.
In web enviroment, mvc cannot be fully (and naturally) implemented, because there's no such event that states a change in model to the view, that's why they came up with the Model 1 and Model 2 things, which are approaches to simulate mvc in a web enviroment.
People who work with web are used to think on 3 tier applications: Presentation, Business, Persistence. So it's natural to make some kind of "mapping" between mvc and 3 tier applications, something i think is
not the best strategy.
In my opinion, we cannot try to make some strong rules. In other words, Business, Presentation, Persisten just don't directly match with Presentation, Model, Control, they are diferent views of an application.
MVC (Model, view=presentation, control) is a higher level abstraction of your application. So you create your business, view and persistence code under this higher level view of mvc. I might be getting confusing here, but i'm trying to make it clear.
The only thing we cannot separate is presentation and view, they are the same thing, but business doesn't map to model or control.
Usually, we implement business in a controller level, but business might also be implemented in the model level. Persistent classes, for example, represent model and we might have some simple business logic there.
So, my advise to you is:
- Presentation logic -> View (M
VC): jsps, html
- Business logic -> Control (MV
C) and Model(
MVC): Action, session ejbs, pojos,etc..
- Persistent logic -> Model(
MVC): persistent classes
Well, as i said, this is my opinion.
[ September 06, 2004: Message edited by: Leandro Melo ]