MVC trivial design

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

MVC trivial design

Post by alex.barylski »

Assuming smarty was my template engine of choice, but other than that I wanted only to use native PHP functions and a single index.php...

How would YOU go abouts implementing even trivial MVC...???

index.php controls smarty...which in turn loads the views...index.php would also handle controller and businness logic/model(via PHP classes which modelled thier objects)

not extensible or anything but i'm just trying to get a batter feel for MVC in a web environment...

So please...offer suugestions, comments, etc...

Except those that start with "Why not just use so an so..."

how is MVC typically implemented in PHP???

Thanks :)
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

Post by neophyte »

If you want to see a massive mvc implementation check out Typo3...
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post by alvinphp »

There is no set way to do MVC as this concept goes well outside of programming. Here is a simplified example of something I have done. This uses plain old PHP 5 without any templates or so called frameworks.

This is the page that is called: index.php?module=cl&action=display&model=ferrari
* index.php is my front controller and when it gets the above url it sees module=cl which is the car list module.
* The index file then includes controller.car_list.inc.php which is my controller for the car list page.
* The control file then sees that action=display so it includes the class that can do this (class.car.inc.php) and then create $obj_car from the class.
* The control file then sees it needs to display all the ferrari models so it calls the method obj_car->display_by_model($inp_model) which gets the list of ferrari models from the database, does a little formatting, and assigns it to a private variable called $_car_list which is in $obj_car.
* The control file then includes view.car_list.inc.php which holds all my dhtml for the car list. This is the view file.
* This view file then outputs the car list by calling $obj_car->get_car_list (accessory method) which grabs the variable $_car_list from $obj_car.

This might look complicated, but with the extensive use of folders it makes a very large site very easy to manage (relatively speaking). I have been doing PHP for barely a year so if there is any major flaws in this I would be happy to here a better way (I am always striving to improve).
Last edited by alvinphp on Wed Dec 21, 2005 3:00 pm, edited 1 time in total.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Last post pretty much said it all. One of the traps of any Design Pattern in PHP is that you may end up with the impression there is a "single best way" to implement it. For simple patterns that's true, for something like MVC its not (regardless of what certain individuals - not on this forum - would claim).

MVC has 3 to 4 components:

- Controller (whatever handles input and output)
- Model (Business Logic; and possibly Data Access if not separated)
- View (lets be very simple and call it Smarty, or Savant, or whatever TE you use)
- Data Access (optional - but generally useful)

My own current "framework", a loosely used term in this case follows the following flow.

1. I have a index.php, or other, which implements a Front Controller (a single point of entry, which centralises common tasks, and is ultimately responsible for handling input Request and output Response).
2. I have a RequestMapper class, which maps a GET or POST variable to a specific Action/Command
3. I have multiple Action/Command classes, e.g. DisplayIndex, SaveUser, NewCart - usually action (not page) based
4. Commands use BusinessLogic and DataAccess classes to perform logical work, DB reads/writes
5. I have a View layer using Smarty or Savant, templates, etc.

A simple example.

I call "index.php?action=show:user&uid=4". This maps to the ShowUserCommand class. The class uses a simpel data access class, e.g. UserDB to look up the user id, and fetch the data. The command class will also assign this data to the view layer - your typical $tpl->assign() calls like Smarty uses. Though usually separate, you could also specify the template here (I tend towards separation so I can easily switch template engines...).

The Front Controller may call upon the View layer to display content from the parsed template.

This is one way of doing MVC - I have lots of other pieces of course, but these are largely marginal extras outside the core MVC pattern itself (i.e. security stuff, request and response class wrappers, etc. - optional though recommended).

Its not perfect - but one OS app I have which does use this type of MVC is a game I work on: http://www.quantum-star.com/devsite/phpbb - if you download, peep inside /system/ and try the installer. Its a work in progress but its small enough to quickly read the code.
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post by alvinphp »

For those serious about MVC and OOP development I strongly suggest you learn UML (Unified Modeling Lanuage). I do not write one line of code till I first create flow charts, use cases, and static structures of both the data and classes. Doing this helps me find a host of potential problems before I start coding which results in a significant reduction in development time.
Last edited by alvinphp on Wed Dec 21, 2005 4:59 pm, edited 1 time in total.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

I haven't read any of the replies, but a really really really (emphasis on really) trivial MVC implementation would go like this.

Code: Select all

<?php

//PHP! I love this script, it was hacked in 5 minutes

//Okay... let's grab all the variables from command line. Nothing else! rawr

//Okay... let's do stuff.

//Let's send it back to the command line now.

//whoo we're done
?>
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

What? :?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Ah... forget it. I was trying to say that MVC is a really simple concept: seperation of Model, View and Controller. How you want to go about implementing it, even if it is as trivial as creating a quick, hacky, transaction script that keeps all the display stuff in one block of code and the logic in another is a good organizational practice, even if it isn't strictly a true seperation.

Bah... maybe I have it all wrong.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Ambush Commander wrote:Ah... forget it. I was trying to say that MVC is a really simple concept: seperation of Model, View and Controller. How you want to go about implementing it, even if it is as trivial as creating a quick, hacky, transaction script that keeps all the display stuff in one block of code and the logic in another is a good organizational practice, even if it isn't strictly a true seperation.

Bah... maybe I have it all wrong.
Nope I think the same.... MVC is one of those concepts that has all kinds of implementations. How you choose to do the separation is up to you... obviously some methods are more logical than others.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Bah... maybe I have it all wrong.
You're perfectly correct. The impression is its complex (I blame the PHP frameworks that publicise their MVC natures). The reality is they are simple - nay intuitive. Most developers stumble into MVC like patterns pretty early on in learning OOP.
Post Reply