PhotoModel vs. WorldController

Ok, everybody is using MVC now. And everybody talks about the best template engine for the View and the best Implementation of PageController pattern or such. One thing that you find only very little definition about is the "M" in MVC. The Model.

Sometimes it is referred to as a ActiveRecord or any other representation of a database row. This appears much too short-minded to me. MVC is about separation of concerns. Who is responsible for what? Clearly, the View should be responsible for visualization of Data. The Controller should control user interaction and page flow. I.e. it recieves all requests, and decides what to do and what do answer after the job is done.

Now, my definition of the Model is: "Facade for the Business logic".

This means not more or less than a small class that offers all the Controller needs to do his work. In my world, the Controller accepts input parameters (GET, POST, SESSION, COOKIE, whatever). It checks for correct syntax and converts into internal formats (example: date fields etc.). The Model will not check for correct number or date formats. The controller then makes a model instance and calls methods with very speaking names in this model. Each Controller uses only one Model. Multiple Controllers may use the same Model if they work in comparable area of concerns.

The model now takes care about all the bits and pieces it needs to process a given task. It reads config, makes DB connections, DataAccess Objects, Entity-Objects (i dont like ActiveRecord, use a JEE-like Entity approach). In bigger projects, your business logic might consist of hundreds of classes, containing factories, singletons and whatever patterns you want to apply. But the Model abstracts this all away from the Controller. This way, the structure of the business logic can be completly changed without impacting the Controllers or even the views.

Models then return all values in internal data representation (example: date as JDDate or PHP-Date). The Controller passes the results to the View. The view is then responsible for giving it the right output format.

This way, also some other responsibilities become clear:

- Syntactical Input Check (including locale aware conversion of typed input fields to internal data formats) happens in the controller

- The Model will check the passed data for consistency

- Output formatting and -escaping of typed data fields is done in the view

- Template translation is done in the view (template engine etc)

- Models (and everything they invoke) may not access $_GET, $_POST, $_REQUEST, $_SESSION, $_COOKIE etc.

- a Model may not invoke any other Model (nor Controller or View).

- Communication between Controller and Model works with internal data representation

For example, the Controller might get the user-id out of the session and transfer it to the Model at initialization time. The model will create a DB connection and a user-object as singletons in the constructor.

... in the controller:

$photoId = (int) $_GET['photoId'];
$albumId = (int) $_GET['albumId'];
$m = new PhotoModel($_SESSION['userId']);
$m->removePhotoFromAlbum($photoId, $albumId);
$res = $m->getAlbumContent($albumId);
$this->view->album = $res;  
// will be rendered by a cool template afterwards

... in the Model:

function __construct($userId) {
     $this->conn = MyDBAbstraction::getConnection($userId);
      $this->user = User::getInstance($userId);
}

etc.

This way, Models stay very lean, at the same time they clearly separate the business logic from the UI logic.

Auf Facebook teilen

« What google knows - Web 2.0 changing the process in WebApp-Development »