Doubts about MVC Model

Question

I've been told that MVC is an architecture pattern for the presentation tier on a multi-tier architecture. I didn't understand the MVC Model concept.

So I made a web application, as an aproach to learn MVC model, only using JSP and Servlets, I made the DataAccess layer too.

In my WebContent folder, I put all the views.

In my src (Java content) folder, I made 4 packages.

data
presentation.model
presentation.controller
businessEntities

I used Servlets as Controllers (used the FrontController pattern) and JSP for all the Views.

As the title says, my problem is with the model.

Now, lets make an example..

I have 2 classes.

 - Car
 - CarLogic

CarLogic is a class that calls a possible CarDAO to get data and to return it to anyone who asks it. Car is just the POJO.

I placed CarLogic inside presentation.model and Car on businessEntities.

Am i wrong? What should i put on Model package?

Thanks!

Answer 1

When nested in the presentation layer of a multi-tier architecture, MVC's models are usually nothing more than (possibly enhanced) key-value maps.

The controller, after having called the appropriate business layer service, instanciate a new map with the values the view will have to display.

Spring MVC for example implemented the MVC pattern this way: see how the ModelMap extends LinkedHashMap.

See this answer to see a typical HTTP request life cycle, when the MVC pattern is nested in the presentation layer of a 3-tier architecture.

So to sum up, I would put CarLogic in your businessEntities package, and the Car POJO within a new presentation.bean package for example (so you won't need your presentation.model package anymore). Thus, your controller would add the Car instance as an attribute of the request, which would then play the part of the model:

request.setAttribute("theBean", yourBeanInstance);

In your JSP views, simply use ${theBean.anyProperty} to access the attribute (don't forget the getter in your bean). Note that the EL will scan the following scopes in given order: page, request, session, application; the first found match will then be returned.

Answer 2

Model View Controller in and of itself is a pretty simple pattern.

From the wikipedia artical:

• A controller can send commands to the model to update the model's state (e.g., editing a document). It can also send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document).
• A model notifies its associated views and controllers when there has been a change in its state. This notification allows the views to produce updated output, and the controllers to change the available set of commands. In some cases an MVC implementation might instead be "passive," so that other components must poll the model for updates rather than being notified.
• A view requests information from the model that it needs for generating an output representation to the user

At least it was simple pre-web and pre-SOA.

The view part is still pretty straight forward, it simply presents the model.

Controller-wise, the web, in its traditional http/html sense rather than the newer JavaScript/AJAX/websocket sense, has made the controllers iteraction with the view much more visible than it was in say a Swing application. This means in addition to their traditional role, controllers in a web-app are likely to not only interact with the model but also have some knowledge of the views.

Model-wise, pre-SOA the model represented both the data and the behaviour of the business. More recently anemic domain models have become popular with behaviour implemented in separate classes from the representation of the data, which is passed to the logic classes (services).

It's this point, relating to the separation of data and logic that I believe your question relates to. Personally, for simple systems, I prefer a rich model with the data and behaviour in the same classes, hence the packaging is simple. However I appreciate that sometimes the benefits in separating the logic from the data and in such cases I'd create a separate package (and probably a separate jar) to contain that logic.