Write your own MVC with PHP

[TomB]

Funny, I've got the exact opposite... more I can do the same way in the controller, the less my models have to do... More I do in the models, the less my view has to do.

The problem is that views are used in multiple places. In this scenario, when a view is changed, all the controllers which use it need to be updated. If I want a new controller which uses the view I need to do all the set up work again, rather than initiating the view and linking it to the model. There's no reason the model can't be substituted for another (and if you're programming around interfaces it's easy). Simply put, the controllers aren't re-used so making them do as little as possible means less repeated code.

where to me that's just another field to be shown, so the view code should be smart enough to iterate the data gathered by the model and say "ok, I need to show this too"

But where does it get the data from? Do you adjust your model to fetch more data in the same function call? What if that's used elsewhere? What if it's used in 10 different places all with slightly different data? That's a lot of extra data being loaded in 9 other places.

[Gibberish]

Personally I haven't come across any reason to create my own MVC framework. I have been using Symfony for quite some time now, having moved from CodeIgnitor and CakePHP, and have found little it couldn't do while keeping processing time low.

[sg707]

MVC is not a rocket science people!

For many reasons I disagree deathshadow60. View not accessing Model? jeez~

This is MVC flow

Http requests -> Master Front Controller -> Business Controller -> Master Front controller -> retrieve and render view template -> Master Front Controller -> client's browser.

When talking about Model. This object should contain the results of the Model DAO. So Business Controller access the Model DAO then passes the Model (Result) to the View. Model is the result! Ok I'm done. Time for more spaghtti code

[TomB]

'Business controller' shouldn't access Model DAO... it should initiate the model it and pass it to the view.The view then accesses the model to request the result. The controller shouldn't be doing anything to do with business logic (e.g. fetching a result) This should be done in the model after it's been passed to the view. In some cases the controller may set options on the view, but it shouldn't directly govern how the model and the view interact.

just because you're calling a function on the model from the controller doesn't mean you've moved the business logic out of the controller.

A good example is pagination. If your controller is doing this:

$perPage = 10;
$page = $_GET['page'];
$users = $this->user->find('lastlogin < "2009-05-10"', $perPage, $perPage * $page);
$totalPages = $this->user->count('lastlogin < "2009-05-10"') / $perPage;
$this->view->assign('users', $users);
$this->view->assign('totalPages', $totalPages);
$this->view->assign('page', $page); 

You have business/display logic in the controller and should be doing something more like this:

$this->view->assign('user', $this->user);
$this->view->assign('filter', 'lastlogin < "2009-05-10"');
$this->view->assign('page', $_GET['page']); 

For several reasons:

• You've removed the business logic from the controller
• The view can now be much more easily re-used, without having to manually work out the options each time.
• Now that the view has access to the model, you have much better control over what the view is doing. Perhaps the view should always add some extra filters, e.g. only users which aren't deleted. Otherwise these extra filters needs to be added in each controller. Perhaps it has different filters based on the current user level? This is all display logic and should be in the view--not the controller.
• The view controls its own error conditions, e.g. it's easy to implement "Sorry, no records were returned but here's some you may be interested in" because it can ask the model for something else. Otherwise you need this logic in the controller too.

[sg707]

'Business controller' shouldn't access Model DAO... it should initiate the model it and pass it to the view.The view then accesses the model to request the result. The controller shouldn't be doing anything to do with business logic (e.g. fetching a result) This should be done in the model after it's been passed to the view. In some cases the controller may set options on the view, but it shouldn't directly govern how the model and the view interact.

just because you're calling a function on the model from the controller doesn't mean you've moved the business logic out of the controller.

A good example is pagination. If your controller is doing this:

$perPage = 10;
$page = $_GET['page'];
$users = $this->user->find('lastlogin < "2009-05-10"', $perPage, $perPage * $page);
$totalPages = $this->user->count('lastlogin < "2009-05-10"') / $perPage;
$this->view->assign('users', $users);
$this->view->assign('totalPages', $totalPages);
$this->view->assign('page', $page); 

You have business/display logic in the controller and should be doing something more like this:

$this->view->assign('user', $this->user);
$this->view->assign('filter', 'lastlogin < "2009-05-10"');
$this->view->assign('page', $_GET['page']); 

For several reasons:

• You've removed the business logic from the controller
• The view can now be much more easily re-used, without having to manually work out the options each time.
• Now that the view has access to the model, you have much better control over what the view is doing. Perhaps the view should always add some extra filters, e.g. only users which aren't deleted. Otherwise these extra filters needs to be added in each controller. Perhaps it has different filters based on the current user level? This is all display logic and should be in the view--not the controller.
• The view controls its own error conditions, e.g. it's easy to implement "Sorry, no records were returned but here's some you may be interested in" because it can ask the model for something else. Otherwise you need this logic in the controller too.

I meant DAO as a Data Access Object. This will initiate a query from db and return model as a result. Perhaps this is what you meant by initiate and send to the view. Yes, I'm sending the result of DAO to the view. Yes I do have a controller that doesn't have any business logic. That's the Front Master Controller. This controller will pass onto corresponding specific business controller depending on the URL. Maybe my business controller has another name like business action class. But why couldn't controller go to another controller? So if my business action class wants to pass along to another controller..then what would this class be? Controller or Action? I just call it controller. Maybe another name is Resource class if you will.

[sg707]

Definitely model should not contain any critical business logic. If it's doing minor validation like length or require check then it's justifiable. But, no processing like storing data into a DB is a definite NO NO!

[TomB]

I'm not sure I understand your architecture but no controller should contain business logic, it's essentially there to initiate the model and the view.

If you're calling a function in the controller which is getting data from the model and passing it to the view, you're doing it wrong in most cases and adding an extra, unnecessary step.

[TomB]

Definitely model should not contain any critical business logic. If it's doing minor validation like length or require check then it's justifiable. But, no processing like storing data into a DB is a definite NO NO!

The model should contain all the business logic. The view should contain all the display logic. The controller should just get those two connected.

edit: You're in a similar position I was until I read this article

[sg707]

The model should contain all the business logic. The view should contain all the display logic. The controller should just get those two connected.

edit: You're in a similar position I was until I read this article

Thanks for the article. I only read about the
"Models Misunderstood" and I still stand that Model is definitely not the place to put business logic.

He says "company internal controls could dictate that purchase orders be subject to a single cash purchase limit of €500. Purchases over €500 would need to be considered illegal actions by your Order Model"

So now you've tied that all Order's can not absolutely go over $500. But, let say you have a requirement that changes this. For example, if it's a corporate customer limit is $50000, web customer is $1000, and POS is $500. Then what? Are you going to pass in the type of customer and do validation in the model? Why would the model care about the type of customer?? then let say we add "discount" logic that is seasonal. Are you going to pass in some special flag to indicate discounts? Model should not have anything beyond getters, setters, and maybe a validate method. only validations they should is like price should be a digit and greater than 0. Anyways, this is from my understanding and I'm sticking to it

[TomB]

The problem is, you're treating a model as if it's a single entity in the system rather than a layer that consists of entities, data mappers, etc. This is a mistake I made too.

The order obviously needs to be linked to a customer at some point.

Oh, and the simplest solution:

class WebCustomer extends Customer {
    public $limit = 1000;
}

class CorporateCustomer extends Customer {
    public $limit = 50000;
}

//...

$order->setCustomer(new CorporateCustomer); 

[rageh]

If you're calling a function in the controller which is getting data from the model and passing it to the view, you're doing it wrong in most cases and adding an extra, unnecessary step.

So where should the function call to the Model object be? in the View? That looks like spaggeti code. What we are talking about is a function, which belongs to the Model object, and pulling data from db. The call to that function should be in the Controller. Surely. Or am I missing something.

Why is it wrong to invoke a Model function returning a resultset, which is passed to the View for presentation? I thought that was neat, and in a way what deathshadow60 considered the best methodolgy. I tend to agree with him on that. Sometimes there are several db calls to get different data. i.e, pupulating title, sidebar, some other snigget(as deathshadow60 eloquently explained). the View going forth and back from the Model in order to fetch the said data again and again is not a good idea. It is no different than spaggeti code. Instead, have all these function calls in the Controller and pass the resultsets to the View in one go. The View should be able to present this neatly without worrying as to whether to have access to the Model directly or not. You may say cut the middeman, but no. The middelman(that is, the controller) is the most important aspect of the whole setup. Everything should go through it. Without the middleman, the model is borken.

Or have I misunderstood the whole thing?

[sg707]

The problem is, you're treating a model as if it's a single entity in the system rather than a layer that consists of entities, data mappers, etc. This is a mistake I made too.

The order obviously needs to be linked to a customer at some point.

Oh, and the simplest solution:

class WebCustomer extends Customer {
    public $limit = 1000;
}

class CorporateCustomer extends Customer {
    public $limit = 50000;
}

//...

$order->setCustomer(new CorporateCustomer); 

Not that I'm a PHP programmer but I rather do

$order.setOrder(order);
$purchaseLimit = CustomerType.CORPORATE.limit;
$status = $orderService.processOrder($order, $purchaseLimit);

This makes the code more reusable. I didn't need to create more classes and I think it's more readable as well. Just as an exageration, let say there's 100 types of customers.. do you think it's reasonable to create 100 models???? that's crazy.

[TomB]

So where should the function call to the Model object be? in the View? That looks like spaggeti code. What we are talking about is a function, which belongs to the Model object, and pulling data from db. The call to that function should be in the Controller. Surely. Or am I missing something.

Why is it wrong to invoke a Model function returning a resultset, which is passed to the View for presentation? I thought that was neat, and in a way what deathshadow60 considered the best methodolgy. I tend to agree with him on that. Sometimes there are several db calls to get different data. i.e, pupulating title, sidebar, some other snigget(as deathshadow60 eloquently explained). the View going forth and back from the Model in order to fetch the said data again and again is not a good idea. It is no different than spaggeti code. Instead, have all these function calls in the Controller and pass the resultsets to the View in one go. The View should be able to present this neatly without worrying as to whether to have access to the Model directly or not. You may say cut the middeman, but no. The middelman(that is, the controller) is the most important aspect of the whole setup. Everything should go through it. Without the middleman, the model is borken.

Or have I misunderstood the whole thing?

All I'm suggesting is moving the call from the controller to the view, which decreases code repetition.

The View always has a contract with a model of some description. Whether it's a primitive array or a complex object it requires the model to have specific data within it, this is naturally unavoidable. By using the Model directly, this contract is immediately fulfilled. If you're passing primitives to the view, it has no way of knowing whether this contract is fulfilled until it breaks... or not. Even if your result set is a set of objects, the view cant know the set is correct (because it's likely a primitive array containing objects) until it tries to use an object. By using the Model, the view can check this contract is fulfilled as the model is assigned to it.

Ignoring this, and assuming your controller always passes a valid data set you still lose re-usability. All the data fetching logic (the call to the model) has to be done on every controller using the view, as I demonstrated using pagination as an example this isn't a good idea as it creates repeated code wherever the view is reused.

Where different models are needed, different models can be passed to the view.

[TomB]

Not that I'm a PHP programmer but I rather do

$order.setOrder(order);
$purchaseLimit = CustomerType.CORPORATE.limit;
$status = $orderService.processOrder($order, $purchaseLimit);

This makes the code more reusable. I didn't need to create more classes and I think it's more readable as well. Just as an exageration, let say there's 100 types of customers.. do you think it's reasonable to create 100 models???? that's crazy.

How are you going to work out what type of customer you're dealing with? $purchaseLimit = CustomerType.CORPORATE.limit; wont work... you'd need a 100 block if-else to work out the correct type...

[level99]

thanks for the opinion. I can understand your point. I know there are many frameworks out there we can use, just like there are many site builders like drupal, wordpress, etc.

my personal problem is, probably I came from the design background, I find very difficult to use wordpress and drupal after many attempts. so I aim to write my own programme to run my website and my freelance websites.

I find the CMS in wp and drupal are very over the top, one of my client hates it (wp's), and I don't know how to fix it when the site having an issue with wp system, so I tend to build my own CMS for myself and clients.

I have learned so much by coding every from scratch on my own! of cos, forums like this help me a lot too!

Hi lauthiamkok,
I would consider using a pre-built framework or CMS such as ExpressionEngine that feels like a framework without having to dig into PHP - and you can expand the cms with your php skills if you like.
Learning the inner workings and the guts of app IS fun but it is also a huge time whole...no need to re-invent the wheel.
Considering that you are a designer by trade (and not a programmer) and if MVC is something you want to learn then I would pick up already made framework (CodeIngiter, Zend etc) and learn it along with the concepts. This way you learn how to use tools vs. how to forge tools. But, I guess it depends what you are after.
For what is worth...
All the best!

[Winged Spider]

Views accessing datalogic and the DAO? Insanity!

That is certainly not MVC. MVC is pretty clear on who does what and I'm pretty sure Java, .Net, and possibly RoR/Django guys would have a heart attack if a Model accessed the database.

If you're calling a function in the controller which is getting data from the model and passing it to the view, you're doing it wrong in most cases and adding an extra, unnecessary step.

But your muddling your separation of concerns. Sometimes adding a Facade layer into your app does introduce duplicated and translation code. The reason you add this Facade is because of abstraction or architecture reasons because you may have to swap out a layer.

A model being coupled to your database layer is really bad news.

[kyberfabrikken]

A model being coupled to your database layer is really bad news.

I don't know about the rest of the platforms you just mentioned, but Rails is notorious for using an active record pattern, which couples model to data access quite strongly.

[sunwukung]

I think some confusion comes from the use of the term MVC, which is perhaps a misnomer. You can't replicate the MVC pattern properly on the web - owing to it's stateless nature:
http://en.wikipedia.org/wiki/Model%E...0%93controller
In this example of MVC - the view renders the Model via an Observer relationship - so while the view isn't manipulating the model, it must be aware of it. MVC wasn't developed in the context of web applications.

what we use is more like n-tier architecture, layered applications. This looks more familiair to me, and more appropriate to the paradigm of web development.
http://en.wikipedia.org/wiki/N-tier

"A fundamental rule in a three-tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middleware tier. Conceptually the three-tier architecture is linear. However, the MVC architecture is triangular: the view sends updates to the controller, the controller updates the model, and the view gets updated directly from the model."

You can see that for n-tier, the controller handles interactions between the view and the model, whereas TomB's approach is more akin to true MVC.

CodeIgniter seems to use n-tier: http://codeigniter.com/user_guide/overview/appflow.html

Zend uses Two-Step transform pattern: http://martinfowler.com/eaaCatalog/twoStepView.html

[TomB]

edit: this was in response to Winged Spider

You're over simplifying it.

The view is accessing the data via the model. The model is the only thing accessing data, how this is done is irrelevant. Again, the model is a layer, not an entity. The model can read the data using a Data Mapper or any other DAO.

I'll quote the wikipedia article on MVC again:

A view queries the model in order to generate an appropriate user interface (for example, the view lists the shopping cart's contents). The view gets its own data from the model. The controller may (in some implementations) issue a general instruction to the view to render itself. In others, the view is automatically notified by the model of changes in state (Observer) which require a screen update.

Want a more academic citation?

http://faculty.washington.edu/hanks/...c_observer.pdf

The views know of the model and will interact with the model.
* If a button is clicked an action message might be sent to a model object in order to get something done.
* If a new value is typed into an entry field an update message might be sent to a model object in order to give it its new value.
 If a value is needed for a display an enquiry message might be sent to a model object in order to get a value.

And here's a whitepaper on the subject:

http://www.itu.dk/courses/VOP/E2005/...r_and_pope.pdf

To maximize data encapsulation and thus code reusability, views and controllers need to know about their model explicitly, but models should not know about their views and controllers.

[TomB]

You can't replicate the MVC pattern properly on the web

I'd disagree on this point. There's no reason you can't keep the state of a model between pages, especially if the only thing the model needs to keep between pages is coming from the database anyway. The only thing that needs to change to accommodate for the web is the controller.

[sunwukung]

Tom is right, in terms of MVC proper, the view does have access to the model, but it's a one way street - but...

"In others, the view is automatically notified by the model of changes in state (Observer) which require a screen update."

It's that reference to "state" that makes the web implementation of MVC slightly out of kilter with the proper definition - since the web is stateless (although you could probably accomplish this via AJAX (hmmm, interesting). I know you can emulate it, but MVC originates in a different environment, where the database can PUSH data into the view. Any updates to the Model on the web are applied in a new request, so the whole shebang is re-loaded anyway.

Winged Spider is arguing from the perspective of n-tier application design, which is more appropriate to the web - but is not MVC.

@kyberfabrikken - As I understand it - Active Record is one of the few patterns that allow this type of coupling, the exception rather than the rule.

[TomB]

Tom is right, in terms of MVC proper, the view does have access to the model, but it's a one way street - but...

"In others, the view is automatically notified by the model of changes in state (Observer) which require a screen update."

It's that reference to "state" that makes the web implementation of MVC slightly out of kilter with the proper definition - since the web is stateless (although you could probably accomplish this via AJAX (hmmm, interesting). I know you can emulate it, but MVC originates in a different environment, where the database can PUSH data into the view. Any updates to the Model on the web are applied in a new request, so the whole shebang is re-loaded anyway.

Why not emulate it though? As long as the controller initiates the same things it's not difficult and the benefits are the same as any other MVC

Take a simple form as an example:

-In model: create form object
-Populate form with existing record data from the database, unless postdata exists, in which case populate from that
-View gets form from model, checks if it's been submitted and asks the model whether it's valid
-View can then display a success message and tell the model to save the form data, or it can display the form again + validation errors

All using a controller which handles both requests using something as simple as:

public function edit($id = null) {
    $model = new Model($id, $_POST);
    $view = new View($model);
    return $view;
} 

[sunwukung]

Why not emulate it? Why bother? What's wrong with n-tier? Surely it's more appropriate to the environment...

-View can then display a success message and tell the model to save the form data, or it can display the form again + validation errors

Even within the context of MVC, the View is a passive observer of the model. It shouldn't tell the Model anything - but it can Observe it's state. To emulate MVC, the model would have to initiate a new request, or use AJAX.

I really think this is a case of crossed wires. What you are saying is entirely workable (barring the statement above IMO), and is the closest match to true MVC. But most web based "MVC" frameworks are not actually MVC, they're n-tier (principally Front Controller) - which is in itself a valid (though distinct) design pattern.

In conclusion, I believe you are right, the View should be granted direct one way access to the Model to render data from it. In Zend, that would have to be achieved with a View Helper or plugin, otherwise the variable pointing to the Model would have been setup in the Controller.

[TomB]

Even within the context of MVC, the View is a passive observer of the model. It shouldn't tell the Model anything - but it can Observe it's state. To emulate MVC, the model would have to initiate a new request, or use AJAX.

You're correct, sending an update from the view directly to the model is wrong and part of the workaround of a single state application. A better solution is to add an extra call to the model in the controller on every request which, on reflection, may be superior.

public function edit($id = null) {
    $view = new View($model);
    $model->edit($id, $_POST); //checks if the form has been submitted and saves if needed
    $model = new Model();
    return $view;
} 

However, now you need the logic checking whether the form has been submitted in both the view and the model. Which is worse? Repeated code or the view issuing a state change to the model?

Or, another solution, where you're assuming the form has been submitted in a second controller function may be equally feasible, if slightly more messy imho.

As for why to not use n-tier... MVC gives you much better reusability, seems silly to use an "MVC framework" which isn't MVC.

edit: Whether you're using AJAX or not is irrelevant imho, keeping states between pages or XHR is the same problem with the same solution.

[sunwukung]

However, now you need the logic checking whether the form has been submitted in both the view and the model. Which is worse? Repeated code or the view issuing a state change to the model?

matter of opinion really - depends if you're a purist, or a pragmatist. In Zend you can pass the form object to the view from the Controller i.e:

$form = new Blah_Form;
if($_POST){
//validate, get messages etc etc.
}
$this->view->form = $form;

Changes to the form are updated dynamically in the view.

edit: Whether you're using AJAX or not is irrelevant imho, keeping states between pages or XHR is the same problem with the same solution.

Yup, it's just smoke and mirrors, that's the problem with emulation...