Help on learning design patten (MVC)

[Resolution]

I jave been designing for some time now - in PHP for 3 years - and I have come to the conclusion that Views should NOT EVER directly manipulate a Controler. Views should only reference controlers ala Hyperlink.

The reason I've come to this conclusion is because a view is simply a portal or a window BUILT FROM the processed buisness logic. The view simply enables the viewer (individual) to more easily digest the raw information from the model. It also serves to organize information from the model in the most efficient mannor which is referenced via the controler/s.

Having worked on my own CMS I initially didn;t know much about book (fowler) logic patterns, I simply worked out the logic myself and did all the MATH by hand until I devised a working patern that now has what people call controlers, views and a model (or models) - though it is NOT a MVC model.

Thanks to many people here (you guys and gals know who you are), I've been reading up on MVC and the like the past year - I just don;t agree with it. I think it's too simple to really solve the problems presented by internet style application elegantly - it's cutting cornors for sake of simplicity.

I could be incorrect, but in the limited experience I have, a View should be the end of the line when it come to logic and anything that happens there should not ever effect the buisness code/process whatsoever.


IS this logical to you?

Interesting post,
Cheers

[Resolution]

I took a look at the post from SIllysoft (thanks) and I see it does in fact say some of the things I stated. I'm still holding to the perception that MVC (or should it be VCM?) is very much simplified in its attempt to explain a workable pattern but, I can see its a good start for anyone who's willing to put in the work and extract the LOGIC that's going to fit thier application.

cheers


PS: An interesting example http://www.geocities.com/pbanta/Mode...ontroller.html

[SamuliK]

Exactly Martin Fowler seriously recommends this approach btw.

Absolutely nothing wrong with this at all actually

I still have the check the data patterns from Fowler's P of EAA more carefully, but for now I would disagree that there is a class for each table in the database. I have in all of my projects had many-to-many relationships, which require a special linking table with just a paired primary key, one id from the first table and another from the second table.

One case being for example a user that belongs to multiple groups and a group having multiple users in it. This requires three tables but probably only translates into two model classes, User and Group.

SamuliK

[HarryF]

Made an attempt at demonstrating the simplest possible MVC example in PHP I could imagine here (pages 9, 10 and 11 are the complete example). May be helps explain what MVC is about.

[Azmo]

I was working on a long rant, but decided I could save a bunch of time by just asking one question:

Would you not agree that for the vast majority of web applications (i.e. PHP scripts), the View layer is represented by the client's browser?

It seems to me that most of the problems people are having with the MVC pattern on these forums are caused by trying to squeeze the entire pattern into their application, when in reality they only need a Controller, a Model layer, and an ResultMessage class (template class).

[sweatje]

Azmo, to some extent, I agree. In the "Industrial Strength MVC" article I wrote for PHP|A I include a figure of the "application stack" in which the template class, resulting HTML and the browser were the "view" portion of the MVC.

[Dr Livingston]

You may find that you do not need in most cases a MODEL for a VIEW in relation to a FORM though by all means you still need the CONTROLLER which controls what the user inputs, ie validation, error trapping etc etc.

As to the point of needing either one main controller or one each per action passed via $_GET then I choose to have one each per action rather than for example one controller using SWITCH to seperate each given action.

Reading some stuff a while back [Thinking In Java I think ?] it was suggested that using SWITCH was a bad idea to base a CONTROLLER on, though why this is so, it wasn't exactly explained

Would be interesting to know why the author stated this though...

[Dr Livingston]

View layer is represented by the client's browser?

Nope. You do not only just have web browser's now. You have Web Tv ? PDAs ? Mobiles ? etc etc

Are you now saying they all represent the VIEW Layer as well ? That's just being silly imo

[Sillysoft]

Made an attempt at demonstrating the simplest possible MVC example in PHP I could imagine here (pages 9, 10 and 11 are the complete example). May be helps explain what MVC is about.

Thanks Harry! It does help me understand better. But I had a question on the tutorial on PHP Patterns. MVC 2 the index.php would be the controller correct? You had a switch in there that deteremined which controller class to run. Is that correct? Meaning are you using the controller to determine which controller to run?

$dao=& new DataAccess ('localhost','','','');
switch ( $_GET['view'] ) {
case "product":
$controller=& new ProductItemController($dao,$_GET);
break;
default:
$controller=& new ProductTableController($dao,$_GET);
break;
 
}
 
$view=$controller->getView();
echo ("<pre>" );
// print_r($controller);
echo ("</pre>" );
echo ($view->display()); 

Silly

[Dr Livingston]

That is one way of doing this though I prefer what is known as mapping ?

Still working on this though myself Btw good article Harry...

[Off Topic] Any news on your forthcoming Site Point book ? [/Off Topic]

[HarryF]

But I had a question on the tutorial on PHP Patterns. MVC 2 the index.php would be the controller correct? You had a switch in there that deteremined which controller class to run. Is that correct?

Yep - in fact that switch which selects a specific controller might be called a front controller. Whether I'd actually do things that way in practice is another question. You may well want to read what's going on in this thread

[Sillysoft]

Yep - in fact that switch which selects a specific controller might be called a front controller. Whether I'd actually do things that way in practice is another question. You may well want to read what's going on in this thread

Another question. Can view be in the controller? Meaning if you have index.php, which is the controller, does the view need to be in a class or can you put html in index.php? Or to build parts of the site do you have multiple view classes? Say to build a header, then a menu, then a second view to get the dynamic info

Silly

[Dr Livingston]

I wouldn't put the View Layer inside the Controller Layer as this breaks the whole purpose of MVC...

As to this wee bit

Say to build a header, then a menu, then a second view to get the dynamic info

I would suggest that you look at the Pattern Template Method at WACT ?

I previously posted the sample script [from WACT] in a thread recently so you may want to have a look back over the last 3 weeks on all posts I've posted to in this period ?

This deals with what your asking from the QUOTE I give me thinks

[Sillysoft]

I wouldn't put the View Layer inside the Controller Layer as this breaks the whole purpose of MVC...

As to this wee bit I would suggest that you look at the Pattern Template Method at WACT ?

I previously posted the sample script [from WACT] in a thread recently so you may want to have a look back over the last 3 weeks on all posts I've posted to in this period ?

This deals with what your asking from the QUOTE I give me thinks

So using MVC what do people normally do when creating a webpage? Follow a design pattern and then a template pattern?

Silly

[sweatje]

So using MVC what do people normally do when creating a webpage? Follow a design pattern and then a template pattern?

Silly

I have the controller determine which view to create (all of my views are classes). The view then loads a template by requesting data from appropriate models. Then the view send the output by rendering the template.

HTH

[Sillysoft]

I have the controller determine which view to create (all of my views are classes). The view then loads a template by requesting data from appropriate models. Then the view send the output by rendering the template.

HTH

Yeah that is what I been doing since starting this thread. I just kept thinking there is one view. So is it safe to say that for each view you create there will be a model for it? (If dealing with a db) So for instance you create the foundation in the view class then have a model/view class to say build a dynamic menu, then another view and model class to create, say a list of items in another section of the page?

Silly

[Azmo]

Nope. You do not only just have web browser's now. You have Web Tv ? PDAs ? Mobiles ? etc etc

Are you now saying they all represent the VIEW Layer as well ? That's just being silly imo

Then please explain how these are different from the web-application's point of view... they all send requests to the application using http, process the resulting document (either XML or one of its subtypes, like HTML), and render it on a display.

The reason I'm saying that the View layer should not be part of a web-application is this: web-applications don't have a user interface the way normal applications do. In normal applications the user interface is an integral part of the application, whereas web-applications rely on remote platforms to process and render XML or HTML documents into a user interface. In normal applications the controller waits for user input (like mouse clicks, and key presses). Web applications don't. They simply process any incoming request, and return whatever [X/HT]ML document is the result of that request.

The browser on the other hand does wait for the user's input. If he clicks on a link, a new request is sent to a webserver; if values are entered into form elements, the View is updated. When the submit button is pressed, all the values of the form are combined into a single request, and again sent to a webserver. This makes the browser slightly more than just the View: it also has some logic to interpret the various document types, and it can handle user input for forms etc. all by itself.

In short, I'd say that MVC in web-applications looks something like this:

- View == webbrowser (or any other platform that renders XML)
- Controller == webserver (+ web-application's controller)
- Model == web-application

The View and Controller communicate using http, the incoming message on the webserver contains the requested action and its parameters, the outgoing message contains the new document to be rendered in the View.

Still sounding silly?

[Selkirk]

Azmo, MVC is simpler than that:

Controller = Input
Model = Processing
View = Output

MVC has experienced a revival in web development because in a web application the distinction between input and output, between request and response, is so well defined as opposed to most GUI applications.

From Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller (MVC)

In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

Translated to the web application: The controller is responsible for Request handling. The view is responsible for Response handling. The model is the logic or processing of the application; the function it provides.

So some theoretical separation of concerns:

• Only the controller can use the PHP request handling functions.
• Only the view can use the PHP response handling functions.
• The model should not directly call either the view or the controller. It can indirectly call the view via events -- see dependency inversion principle (PDF).
• The view should not directly call the controller.
• The view can access the model for informational purposes, but should not attempt to make state changes.
• The controller has access to both the view and the model.

To confuse things, there is another pattern called Presentation, Abstraction and Control. This is similiar to Ivar Jacobson's Interface objects, entity objects and control objects in OOSE which introduced use cases evolved into the Rational Unified Process. This divides responsibilities slightly differently:

Presentation - Both Input & Output
Abstraction - Information
Control - Behavior

From OOSE:

The control objects typically act as glue which unites the other objects so they form one use case.
...
Typical types of functionality placed in the control objects are transaction-related behavior or control sequences specific to one or a few use cases.

[soapsud]

great explanation selkirk!

[Azmo]

From the Pragmatic Programmers:

A Pattern is a relatively new idea in computer science. It attempts to document a solution to a problem in a given context.

Here's the problem I have with MVC in web-applications: the pattern has been taken out of its original context (complete real-time application with its own user interface), and has been redefined in a new context (web-applications, relying on a separate webserver and remote client). Not only do you end up with two rather different descriptions of the 'same' pattern, but each description is also invalid for the other context. I can understand why so many people are confused about MVC after reading about it on the internet (I sure was at first); there are two distinctly different patterns out there using the same name...

A normal application based on MVC should be fully capable of being executed without help from external programs, right? The Model, View, and Controller can take care of every aspect of the application. But how does a PHP script based on MVC fare without the webserver or the webbrowser? We've already accepted the fact that the webserver can be the (Front) Controller, why is it impossible that the webbrowser is the View?

And I'm asking this from the perspective of the original MVC pattern, not the anti-pattern version used by many webdevelopers.

[Dr Livingston]

Silly ? Not picking an argument folks though I still think that a web browser does not represent the View layer, likewise a web server does not represent the Controller layer, as suggested in another thread by HarryF

[Selkirk]

While MVC is typically taught in the context of GUI development, it is really a general-purpose programming technique. The view is an interpreetation of the model (perhaps a subset) -- It doesn't need to be graphical. The controller is more of a coordination mechanism, and doesn't have to be related to any sort of input device.

• model The abstract data model representing the target object. The model has no direct knowledge of any views or controllers.
• View A way to interpret the model. It subscribes to changes in the model and logical events from the controller.
• Controller A way to control the view and provide the model with new data. It publishes events to both the model and the view.

I think this book is getting a bit dated regarding MVC. I think most people today learn MVC as a result of web development, not GUI development. The books treatment of MVC is very GUI oriented.

The HTTP protocol's strict sequencing of input and output has revived the original small talk definition of MVC where the controller handles input.

The View and controller are tightly coupled, and in some implementations of MVC the view and the controller are a single component.

Rewrite this sentence with an input/output viewpoint:

The output and input are tightly coupled, and in some implementations the output and input are a single component.

This is a very PAC-oriented viewpoint and probably true in GUI development. Presentation components handle BOTH input and output. However, in the web world, the input and output are not as tightly coupled, as the HTTP protocol distinctly divides them.

Here's the problem I have with MVC in web-applications: the pattern has been taken out of its original context (complete real-time application with its own user interface), and has been redefined in a new context (web-applications, relying on a separate webserver and remote client).

It works well in a web context. Perhaps better than it did in the GUI context.

Not only do you end up with two rather different descriptions of the 'same' pattern, but each description is also invalid for the other context. I can understand why so many people are confused about MVC after reading about it on the internet (I sure was at first); there are two distinctly different patterns out there using the same name...

Yes, but the web-MVC of the 2000's is the SAME as the smalltalk GUI-MVC of the 1980's. Its the GUI-oriented MVC of the 1990's that went in a different direction. ( A time, I might add, where you were considered an OO programmer if you knew how to drag a pre-made component from a palette to a window in an IDE. )

The point of MVC is to separate things that change at different times for different reasons. The model changes based on business requirements. The view changes based on output requirements. The controller changes based on input requirements.

In practice, PHP is a special purpose language designed for web applications. This has nothing to do with the MVC pattern.

Here is Martin Fowler's take on this:

The fact that most GUI frameworks combine view and controller has led to many misquotations of MVC. The model and the view are obvious, but where's the controller? The common idea is that it sits between the model and the view, as in the Application Controller (pattern) -- it doesn't help that the word "controller" is used in both contexts. Whatever the merits of an Application Controller, it's a very different beast from an MVC controller.

[Dr Livingston]

The view changes based on output requirements.

Exactly as to why I do not see the web browser acting as the View layer; It is the web page that acts as the UI and not the browser, which only implements what the server sends to it

Anyways, this is proberly off topic but I'm currently reading this article at the moment - the reason I've come back to this thread after leaving it for the day

Enjoy.

http://www-106.ibm.com/developerwork.../j-oobuilding/

[Sillysoft]

I have the controller determine which view to create (all of my views are classes). The view then loads a template by requesting data from appropriate models. Then the view send the output by rendering the template.

HTH

So I just wanted to verify. Is it safe to say that you could have a model for each view? Meaning could a web page template be made up of multiple views with models? For instance one view/model creates the header/footer, while another view/model creates a menu and then another view/model that creates the dynamic information in the middle?

Silly

[sweatje]

So I just wanted to verify. Is it safe to say that you could have a model for each view? Meaning could a web page template be made up of multiple views with models? For instance one view/model creates the header/footer, while another view/model creates a menu and then another view/model that creates the dynamic information in the middle?

Silly

The relationship is really many to many, i.e. a view could use one or none or many models, and a particular model could by used more than one view.