Understanding the MVC Pattern

As for the criticism within my post I thought I would give a post on how i tend to create an MVC Pattern in PHP

Within PHP i spit the framework up into several sections, of witch some are the normal when it comes to MVC.

Primaries:

  • Controller
  • Model
  • View

Secondariness - ModelLayer

  • ViewLoader
  • Library
  • ErrorLayer

Within the controller I usually allow all access the secondary layers and the View and Model from Primary.

Here's the way I would structure it

|---------|       |------------|       |------------|
| Browser | ----> | Controller | ----> |   Model    |
|---------|       |------------|       |------------|
     |                  |   |                |
     |                  |   |----------------|
     |                  |
     |            |------------|
     -------------|    View    |
                  |------------|

From my diagram I usually bypass the View <-> Model connection and do a Controller <-> Model and then the link from Controller <-> View assigns the data.

Within my framework I tend to create a object storage system so that i can easily fetch objects and so forth. an example of my object storage is like so

class Registry
{
   static $storage = array();

   public static function get($key)
   {
       return isset(self::storage[$key]) ? self::storage[$key] : null;
   }

   public static function set($key,$object)
   {
       self::"storage[$key] = $object;
   }
}

Somewhat more advanced by that's the outline, so with this when I first initialize objects i store them like Registry::set("View",new View()); so that there always accessible.

So within my controller witch is the base controller i create several magic methods __get() __set() so that any class that extends the controller I can easily return teh request for example:

abstract class Controller
{
   public function __get($key)
   {
       //check to make sure key is ok for item such as View,Library etc

       return Registry::get($key); //Object / Null
   }
}

And the user controller

class Controller_index extends Controller
{
    public function index()
    {
       $this->View->assign("key","value"); // Exucutes a method in the View class
    }
}

The model will also be placed into registry but only allowed to be called from ModelLayer

class Model_index extends ModelLayer_MySql
{
}

or

class Model_index extends ModelLayer_MySqli
{
}

or filesystem

class Model_file extends ModelLayer_FileSystem
{
}

so that each class can be specific to the storage type.

This is not the Traditional type of MVC Pattern but it can be called Adoptive MVC.

Other objects such as the View Loader should not be placed into registry as there not specifically for the users interests but used by other entites such as View

abstract class ViewLoader
{
   function __construct($file,$data) //send the file and data
   {
       //Include the file and set the data to a local variable
   }

   public function MakeUri()
   {
       return Registry::get('URITools')->CreateURIByArgs(func_get_args());
   }
}

as the template file is being included in the View loader and NOT the View class it separates the user methods from teh system methods and also allows methods to be used within the views themselves for general logic.

Example of template file.

<html>
   <body>
      <?php $this->_include("another_tpl_file.php"); ?>
      <?php if(isset($this->session->admin)):?>

          <a href="<?php echo $this->MakeUri("user","admin","panel","id",$this->session->admin_uid) ?>"><?php echo $this->lang->admin->admin_link ?></a>

      <?php endif; ?>
   </body>
</html>

I hope my examples help you understand that little bit more.


Answer to the third question:

When the model changes, it notifies the view, then the view gets the data from the model using its getters.


The easiest way to get a handle on MVC is to use it in a framework that enforces it, that being said..

  • The Model interacts with the datasource (DB or whatever) and gives you access to your data.
  • The View interacts with the outside world, it receives input from somewhere and hands off the data to the Controller it also listens to the Controller to make sure its displaying the correct data.
  • The Controller is where all the magic happens; the Controller manipulates data, pushes events, and handles changes in both directions (to/from the View and to/from the Model).

This diagram is very helpful (it makes much more sense than Wikipedia's): MVC Diagram

Source, and a great article on MVC!