nemetral.net » Patterns http://nemetral.net Insightful posts on design and code. Mon, 18 May 2009 19:39:39 +0000 http://wordpress.org/?v=2.7 en hourly 1 MVC dilemma http://nemetral.net/2008/10/15/mvc-dilemma/ http://nemetral.net/2008/10/15/mvc-dilemma/#comments Wed, 15 Oct 2008 21:18:42 +0000 nemetral http://nemetral.net/?p=274
  • A gentle introduction to MVC (part 3) In part 1, we decoupled a vanilla PHP script and...
  • A gentle introduction to MVC (part 2) In part 1, we saw how to decouple a traditional...
  • A gentle introduction to MVC (part 1) MVC is certainly the widest spread architectural pattern in today's...
    • ]]>     The most interesting questions often arise after theory has been explained, when getting hands dirty trying to write some code, organize and design a software architecture or start compiling existing snippets into a comprehensive framework. Following my posts on MVC (see and digg the “A gentle introduction to MVC” series: Part 1, Part 2 and Part 3), a reader recently asked me a couple of questions related to common MVC implementation issues.

    I had a couple of questions with respect to your articles on gentle introduction to MVC. I *really* want to understand MVC. I have little experience with web development, so the things that I develop look “okay” on the surface, but they are messy underneath. I read so much about MVC that confused the heck out of me but then I finally came across your simple intro, and I think it’s a really nice start for me. If you wrote a book about more on the concept, I’d be the first to buy it. I think that I understand the general idea, but I think I’m having a tricky time with implementation. I would *really* appreciate if you could answer a couple of questions..

    1. Mapping between controllers and models:

    As part of a lab booking system that I’m working on, one screen handles the showing of existing bookings, addition of new bookings, and deletion of bookings. I call it “SAD” (show, add, delete). I’m having trouble with the SAD controller and SAD model. In my test “router”, I call the SAD controller if I see (through POST) the need to show/add/delete bookings. The SAD controller instantiates the SAD model .. it’s not quite clear if there’s always a one-to-one mapping between a view, controller, and model or whether my concept of a SAD controller and SAD model right from the get-go isn’t correct?

    MVC is to be understood as a general guidance regarding code decoupling and organization. As such, there is no strict MVC rule requiring to map certain controllers to certain models. MVC can be implemented in various ways: the diversity of existing frameworks is certainly the best evidence of it. Back to your question: your concept of one SAD controller and one SAD model is right. I wouldn’t call it “SAD” though but rather “Bookings”, because the “SAD” operations can be executed on many different types of data (blog posts, users, images etc.): I personally always call controllers and associated models by the type of data they represent (as many other CodeIgniter hackers do) knowing that similar operations will be executed on them all (what you call “SAD”, which is by the way usually dubbed as CRUD for Create, Read, Update and Delete). Concerning the router: I usually prefer to rely on GET variables rather than POST variables (see my post about REST), i.e. configure the router so that it loads the controller when specific URLs are called. Both my controller and model are objects: for my controller, the object’s name would here be Bookings and each action I can undertake would be a method in my object. Here is some sample code for the object’s structure:

    <?php

class Bookings
{

   public function add()
   {
      // code goes here
   }

   public function edit()
   {
      // code goes here
   }

   public function delete()
   {
      // code goes here
   }
}

?>

    Each one of these methods would be bound to a specific URL:

    • the add method would be bound to http://example.com/bookings/add
    • the edit method would be bound to http://example.com/bookings/edit
    • the delete method would be bound to http://example.com/bookings/delete

    The router’s job is to effectively bind the URLs to the correct controller and methods (see some code snippets in Part 3 of my MVC series of post). Some methods may require a model, some other may not: this is why it is a good practice to instantiate the model from the called method of the controller. Say the add method requires the Bookings model, then I would instantiate it inside the method. Concerning the view, there will certainly not be a one-to-one mapping between the Bookings controller and the Bookings view: I need a specific view with a HTML form to add bookings, another one with another form to edit existing bookings but I don’t need a view for bookings deletion. These views can be seen as “sub views” (only the HTML forms) which can in turn be embedded into a more general view called a layout. To summarize, I would have a Bookings controller instantiated by the router, a Bookings model instantiated within the controller’s methods (if needed), a Bookings HTML layout (containing the <head> and most of the <body> tags) and several sub views inserted inside the layout depending on the controller’s method called.

    2. User authentication

    Now, let’s say that I want to add a booking - that is, a user types a booking name onto the SAD (view) , and clicks the “NEW” button. Is it the SAD controllers job to determine whether the user has access to write the booking or not and then to pass the request on to the SAD model for the actual write? Right now, $_SESSION['access'] has that detail, and the controller checks it, but I don’t know if that’s right. When it comes to actually writing the booking — the SAD model just uses a PHP class called “booking” that abstracts the booking idea (XML files for bookings). However, do I need to have a stub function for the “write()” call from class Booking in the SAD model class so that the controller can call it without having any understanding about the details of how a booking is stored?

    Checking whether a user is allowed to interact with data is indeed part of the controller’s job, so what you’re doing there is perfectly in line with MVC principles. First the router maps a URL to a controller and a specific method; then the called method will find who the user is, what he can or can’t do and will therefore allow him to perform a specific action or not. If the action requires interaction with data, then the controller will delegate the task to its model (which in turn will typically be an object with methods like add(), edit(), delete() etc.). Either the model’s methods directly call the database and perform the action, or you can insert another layer of abstraction and further delegate the job to a specific class so that you can easily switch storage support (database, XML files etc.) later on for example. So the answer is: it mainly depends on the complexity of your project. Either you know you’ll stick to XML files and you can directly write the code in the model’s methods, or you’re not sure about it and call a third-party library to handle it.

    3. Designing methods in the controller’s object:

    I then have another class called “BookingDatabase” which knows how to see a list of all bookings, check if one exists, etc. If I want to check if a booking exists in the SAD controller before I call the “add booking” function in the SAD model, do I need to have a stub for the “exists” function from the BookingDatabase class in the SAD model as well so that the controller can check if a booking exists before writing it?
    Now, let’s say I have another screen — the “EDIT” screen. I would then have an EDIT model and an EDIT controller — but this would need to write bookings as well — would the “edit” model then need to have it’s own stub of the booking classes write function?
    Assuming that it makes sense to have an add_booking function in the SAD model — does it make sense to have one in the controller as well? The one checks that the user has access to write the booking, that the booking doesn’t already exist, that the booking name is valid (using functions from the model) and then calls the add_booking function from the SAD model to write the booking?

    According to the structure I previously suggested, the edit action should be handled by the Bookings controller together with the Bookings model. So the edit feature would be implemented as a method in the Bookings controller, bound to a specific method in the Bookings model in charge of effectively editing the selecting records (through a third-party library or not). This method would call the main layout of the application but would insert a specific view in it: the edit view containing the HTML form. The other point you raise here is correct: you can check if a booking already exists in the Bookings controller by calling a specific method in the Bookings model. And the whole process you describe concerning the add_booking function is perfectly in line with MVC principles too.

    4. Enhancing the views

    A couple of my views have a couple of small associated javascript functions. Where do they go? Do they remain in the view? I’ve stuck them in the “controllers” directory in a separate .js files, added them to the view files.

    Views are basically HTML files, and as such they can be enhanced with CSS and JavaScript. So these external sheets should be located in the same directory than the views. That said, this kind of organization depends on the framework you’re working with: with CodeIgniter, views are located far away in the arborescence and it’s a pain to insert CSS and JavaScript sheets, so I usually relocate them just one folder away from the root. As they can be located anywhere, it’s better to choose a folder close to the root as it’s easier to call them from the HTML views.

    Conclusion

    Almost everything I know in computer science was learnt the hard way (trial-and-error) or by reading tutorials or forums where hackers kindly explained stuff down to implementation details. Now that I have some experience and background in the industry, I am particularly glad to share what I know with you all. Don’t hesitate to send me questions and I shall publish an answer that will surely be useful to everybody.

    Related posts:

    1. A gentle introduction to MVC (part 3) In part 1, we decoupled a vanilla PHP script and...
    2. A gentle introduction to MVC (part 2) In part 1, we saw how to decouple a traditional...
    3. A gentle introduction to MVC (part 1) MVC is certainly the widest spread architectural pattern in today's...

    ]]>     http://nemetral.net/2008/10/15/mvc-dilemma/feed/     A gentle introduction to MVC (part 3) http://nemetral.net/2008/08/13/a-gentle-introduction-to-mvc-part-3/ http://nemetral.net/2008/08/13/a-gentle-introduction-to-mvc-part-3/#comments Wed, 13 Aug 2008 05:00:24 +0000 nemetral http://nemetral.net/?p=55
  • A gentle introduction to MVC (part 2) In part 1, we saw how to decouple a traditional...
  • A gentle introduction to MVC (part 1) MVC is certainly the widest spread architectural pattern in today's...
  • MVC dilemma The most interesting questions often arise after theory has been...
    • ]]>     In part 1, we decoupled a vanilla PHP script and separated the business logic from the presentation. In part 2, we added a third element in the mix called the model and dedicated to the data access layer. It is now time to spice up the coding by introducing the role of Object-Oriented Programming in a MVC architecture and release the very basis (for educational purpose only) of a MVC framework.

    Part 3: OOPs I’ve added objects

    As you all know, OOP is famous for wrapping functions and variables into higher-level elements called objects (if you’re not familiar with OOP, I suggest you have a look at the Wikipedia page and some tutorials). So here is how we could merge MVC and OOP for a greater code flexibility, reusability and maintainability:

    • the controller is an object: in CodeIgniter for example, the first segment of the URL is the name of the controller’s object and the second segment is the name of the controller’s method which needs to be run (for example, calling http://community.com/members/show would trigger the instantiation of the members object and the call of the show method)
    • the model is an object: as a representation and abstraction of the data, the model is also an object (let’s call it members_model) and contains functions such as getAllMembers() for example
    • the view can be an object too: with general functions such as getTemplate() which selects the corresponding template or renderHTMLPage() which fills the HTML page with the data and outputs the result; but the templates (and sub-templates) are plain PHP/HTML files (let’s call the layout template members_view.php)
    • the router is a plain vanilla PHP file which essentially checks the validity of the request and loads the correct controller

    Now if we translate these principles into actual PHP code, here is what a very raw MVC framework could look like (directly inspired from CodeIgniter):
    Tree structure:

    index.php
   /controllers
      members.php
   /models
      members_model.php
   /views
      members_view.php
      /tpl
         header.php

    file: index.php

    <?php 

$request = preg_replace("|/*(.+?)/*$|", "\\1", $_SERVER['PATH_INFO']);
$uri = explode('/', $request);

include 'controllers/' . $uri[0] . '.php';
$controller = new $uri[0];
$controller->{$uri[1]}();

?>
    1. index.php is called in the URL
    2. takes the PATH_INFO (here: /members/show/) and cleans the starting and trailing slashes using a REGEX
    3. explodes the URL into $uri[0] (name of the requested controller) and $uri[1] (name of the requested method)
    4. instanciates the controller and calls the method

    file: controllers/members.php

    <?php

class members
{
  function show() {
    include 'models/members_model.php';
    $model = new members_model();
    $members = $model->getAllMembers();

    include 'views/members_view.php';
  }
}

?>
    1. to simplify, there is no constructor and the function show() is directly run
    2. the method show() loads and instanciates the correct model, calls the method to get all the members and fills the $members variable with the data
    3. then the method show() loads the correct view: the latter is automatically parsed (the data contained in the $members variable is inserted in-between HTML tags) and output

    file: models/members_model.php

    <?php

class members_model
{
   function members_model() {
     $connection = mysql_connect('host', 'user', 'password');
     mysql_select_db('database', $connection);
   }

   function getAllMembers() {
     $data = mysql_query('SELECT name FROM members');
     $members = array();
     while ($item = mysql_fetch_array($data)) {
       $members[] = $item['name'];
     }
     return $members;
   }
}
    1. there is a constructor establishing once for all the connection to the database
    2. the method getAllMembers() queries the database, extracts the members’ names and returns them through an array

    file: views/members_view.php

    <html>
  <?php include 'views/tpl/header.php'; ?>
  <h1>Members of community.com:</h1>
  <ul>
  <?php for ($i = 0; $i < count($members); $i++) : ?>
    <li>Member #<?php echo $i + 1; ?>: <?php echo $members[$i]; ?></li>
  <?php endfor; ?>
  </ul>
</html>

    file: views/tpl/header.php

    <head>
  <title>Community.com rocks!</title>
</head>
    1. the main layout members_view.php is included by the controller and therefore automatically parsed
    2. the layout includes a reusable template for the header

    Note: this code is for educational purpose only.

    As you can see, building a OO MVC architecture is not that difficult. Please bear in mind that the code above is a basic way of achieving a MVC architecture and a lot of things could be improved:

    • first thing to do is to dramatically enhance the router file: there is no checking on whether the requested controller exists or not, and is accessible or not (this is a huge security hole)
    • instead of getting connected to the database in the model’s constructor, why not creating a model superclass managing the database connection and make each model an extension of this superclass? This way we could use several models from our controller without worrying about being already connected to the database or not
    • in the same way, why not creating a controller superclass with common features and make each controller an extension of this superclass?

    Now CodeIgniter has all that.. and much more. It is secure, lightweight and brillantly coded. If you want to start coding MVC, CodeIgniter is a must have!

    Related posts:

    1. A gentle introduction to MVC (part 2) In part 1, we saw how to decouple a traditional...
    2. A gentle introduction to MVC (part 1) MVC is certainly the widest spread architectural pattern in today's...
    3. MVC dilemma The most interesting questions often arise after theory has been...

    ]]>     http://nemetral.net/2008/08/13/a-gentle-introduction-to-mvc-part-3/feed/     A gentle introduction to MVC (part 2) http://nemetral.net/2008/08/06/a-gentle-introduction-to-mvc-part-2/ http://nemetral.net/2008/08/06/a-gentle-introduction-to-mvc-part-2/#comments Wed, 06 Aug 2008 05:00:44 +0000 nemetral http://nemetral.net/?p=49
  • A gentle introduction to MVC (part 3) In part 1, we decoupled a vanilla PHP script and...
  • A gentle introduction to MVC (part 1) MVC is certainly the widest spread architectural pattern in today's...
  • MVC dilemma The most interesting questions often arise after theory has been...
    • ]]>     In part 1, we saw how to decouple a traditional vanilla PHP script so as to separate business logic from presentation. This was the biggest step to make: from now on, we are just going to finetune this separation by adding a 3rd guy in the equation: the model. Ladies and gentlemen, this is part 2 of A gentle introduction to MVC.

    Part 2: fully MVC-powered goodness

    MVC stands for Model/View/Controller. It’s a software design pattern advocating the use of three layers:

    • the model: the model is the data access layer, the one responsible for gathering the data asked by the request (i.e. functions like getAllMembers() returning a PHP array with all the members in it, or addMember($name, $age, $city) to add a new member to the database)
    • the view: the view is the presentation layer in charge of generating the output (i.e. the final HTML webpage featuring the names of the members with PHP used as a template language as in <li><?php echo $member['name']; ?></li>)
    • the controller: the controller is aimed at coordinating the whole process by analysing the request, running the corresponding model to get the data (i.e. calling getAllMembers() and put the return array in the PHP variable $members), call the corresponding view (i.e. include 'tpl/template.php') and fill it with the data (i.e. $members), and then send the final output back

    Here is a simple graph to better understand the MVC design pattern:

    This new architecture gives more flexibility when building the application:

    • the data access layer is outsourced to the model so that we can work with an abstraction of data: the actual storage of data may be a database, XML files or a hash table, we will still access the list of members through the function getAllMembers()
    • the presentation layer is outsourced to the view: if we want the output to be a RSS feed instead of a HTML page, we just have to change the view without interfering with the logic or the data access

    As you can see, MVC is extremely powerful because it makes it possible to split down the script in naturally independant parts, which in turn makes the old reusability dream come true: for example, if we want to output both a HTML page and a RSS feed featuring all the members of community.com, we can reuse the same model and simply create two different templates (say 'tpl/template.php' and 'tpl/rss.php').

    Now let’s turn to a substantial implementation of the MVC design pattern. Calling directly the controller through http://community.com/members.php can be enhanced through a little bit more of decoupling: instead of calling directly the script, we will call a single-entry point called the router specifying that we want to display the members’ page, and this router will analyze the request, understand that we want to display the members’ page and run the members.php controller. In CodeIgniter for example, the single-entry point is called index.php and if we want to call the members controller, we have to type the following url: http://community.com/index.php/members. We could also imagine a less-sexy http://community.com/index.php?controller=members or, on the contrary, get rid of the router through some URL rewriting and just having to call an elegant http://community.com/members.

    Here is what we have added or clarified in this example of MVC implementation:

    • the router is now the single entry-point of the application which analyzes each request and loads the corresponding controller
    • the model interfaces with a database (once again, it could be a set of XML files or any other way of storing data, we would just have to rewrite the model without worrying about the final output providing that we deliver the expected data)
    • the view now becomes a main layout which in turn can include reusable sub-templates (this is directly inspired from Ruby on Rails and has been reproduced in many web frameworks)

    (Go to part 3)

    Related posts:

    1. A gentle introduction to MVC (part 3) In part 1, we decoupled a vanilla PHP script and...
    2. A gentle introduction to MVC (part 1) MVC is certainly the widest spread architectural pattern in today's...
    3. MVC dilemma The most interesting questions often arise after theory has been...

    ]]>     http://nemetral.net/2008/08/06/a-gentle-introduction-to-mvc-part-2/feed/     A gentle introduction to MVC (part 1) http://nemetral.net/2008/07/31/a-gentle-introduction-to-mvc-part-1/ http://nemetral.net/2008/07/31/a-gentle-introduction-to-mvc-part-1/#comments Thu, 31 Jul 2008 05:00:21 +0000 nemetral http://nemetral.net/?p=33
  • A gentle introduction to MVC (part 3) In part 1, we decoupled a vanilla PHP script and...
  • A gentle introduction to MVC (part 2) In part 1, we saw how to decouple a traditional...
  • The pursuit of APIness (part 5) XML-RPC is damn easy to use and many projects still...
    • ]]>     MVC is certainly the widest spread architectural pattern in today’s webdevelopment landscape. Brought back to fashion by Ruby on Rails from 2004 on, it has been translated and implemented into many languages and more than 100 web frameworks. This illustrated three-part is aimed at helping you cross the gap between a traditionnal vanilla PHP script and a full MVC implementation.

    Part 1: decoupling a traditional webpage

    Remember community.com? Here is what could be the server-side script used to generate a page featuring all the website’s members (assuming an average use & level of vanilla PHP):

    <html>

  <?php include 'inc/header.php'; ?>

  <h1>Members of community.com:</h1>
  <?php
    // INITIALIZING THE DATABASE
    $connection = mysql_connect('host', 'user', 'password');
    mysql_select_db('database', $connection);
    // PULLING OUT THE DATA
    $data = mysql_query('SELECT name FROM members');
    // DISPLAYING THE DATA
    echo '<ul>';
    $i = 1;
    while ($member = mysql_fetch_array($data)) {
       echo '<li>Member #' . $i . ': '. $member['name'] . '</li>';
       $i++;
    }
    echo '</ul>';
  ?>

</html>

    with inc/header.php being like:

     <head>
    <title>Community.com rocks!</title>
 </head>

    Note: this is still very basic HTML without DOCTYPE

    Since data is pulled out from the database in the middle of HTML tags, each time you need to display the members’ names, you need to rewrite the PHP/SQL snippet, which makes it more difficult for your code to be maintainted. Still, although not being a flawless, this is not dumb writing neither: we can see the ghost of a decoupling through the use of include, which makes it possible to start splitting the code into reusable parts (e.g. the header).

    Here are a few things we could do to enhance the organization of this script:

    • remove all the PHP logic (e.g. querying the database, formatting data etc.) from in-between HTML tags and paste it all above the first <html> tag
    • use PHP variables (filled with the data pulled out from the database) to carry data in-between the HTML tags
    • step further in decoupling and split the script into two files: one for the logic and the other for the presentation (based on the PHP variables)

    Here is a simple graph to better understand the process:

    Step 1 is the original PHP script where business logic (which query to execute, pulling out data from the database etc.) is mixed with HTML tags. In Step 2, we isolate the logic at the beginning of the script, keep the HTML tags at the bottom of the script and link the two using PHP variables. Step 3 is the final step: we simply split the script in two files (one for the logic and the other for the HTML presentation). Applied to our code, here would be the result at step 3:

    <?php
  $connection = mysql_connect('host', 'user', 'password');
  mysql_select_db('database', $connection);

  $data = mysql_query('SELECT name FROM members');
  $members = array();
  while ($item = mysql_fetch_array($data)) {
    $members[] = $item['name'];
  }

  include 'tpl/template.php';
?>

    with tpl/template.php being like:

    <html>
  <?php include 'tpl/header.php'; ?>
  <h1>Members of community.com:</h1>
  <ul>
  <?php foreach ($members as $i => $member) : ?>
    <li>Member #<?php echo $i + 1; ?>: <?php echo $member; ?></li>
  <?php endforeach; ?>
  </ul>
</html>

    Note: when using PHP as a template engine (this is what we are doing in the second file), it is quite common to use alternative structures. Also note that I changed the ‘inc’ directory for a ‘tpl’ directory, the latter being in charge of gathering all template files (so tpl/header.php in step 3 is the same file than inc/header.php in step 1).

    Once parsed, you will get the following HTML output (supposing there are only two members Anna and Lisa):

    <html>
  <head>
    <title>Community.com rocks!</title>
  </head>
  <h1>Members of community.com:</h1>
  <ul>
    <li>Member #1: Anna</li>
    <li>Member #2: Lisa</li>
  </ul>
</html>

    Let’s now zoom out from the script and have a look at the whole request/response structure. When calling http://community.com/members.php, here it what happens:

    1. members.php gets connected to the database, pulls out the members’ names and fills an array with them (called $members)
    2. members.php includes the template file in which $members is looped through so as to produce the final HTML

    This could be called a View/Controller architecture, where members.php is the controller and tpl/template.php the view:

    Proceeding like this makes it possible to separate logic from presentation: first we run all the queries and then we generate the HTML page using PHP variables.

    (Go to part 2)

    A comments thread is available on CodeIgniter Forums

    Related posts:

    1. A gentle introduction to MVC (part 3) In part 1, we decoupled a vanilla PHP script and...
    2. A gentle introduction to MVC (part 2) In part 1, we saw how to decouple a traditional...
    3. The pursuit of APIness (part 5) XML-RPC is damn easy to use and many projects still...

    ]]>     http://nemetral.net/2008/07/31/a-gentle-introduction-to-mvc-part-1/feed/