The MVC's model

[PCSpectra]

I'm just playing devils advocate here, but...

the view only ever gets data from the model. There is a reason for this: the model is the only place which holds data.

I don't think this is what he is challenging. I thnik he is saying that it is possible (in an MVC architecture) to have different dependencies. Most articles, books, etc on MVC refer to the classical paradigm.

I think what Tony is adovocating, and I have to agree, is that in web-MVC ( http://martinfowler.com/eaaDev/PassiveScreen.html) the dependencies change quite substantially because of the request-response cycle, as opposed to real-time, event based based environements.

In passive view, the controller queries the the model and feeds the views, as opposed to the view having a dependency on any model. This creates a one-way dependency from the controller to the model and controller to the view, in theory making each component more reusable.

Of course, as you noted with the pager, this is not always the best approach, but it really depends on context, which is where I think Tony and you differ most.

Cheers,
Alex

[TomB]

Actually this is something Tony and I agree on:

Why should the MVC pattern in a desktop application be different from the MVC pattern in a web application. Of course the implementation is different, but the pattern remains the same.

Martin Folwer is in fact not discussing MVC there. It's a variant of MVP:



Source: MSDN: http://msdn.microsoft.com/en-us/library/ff647543.aspx


He even says so himself:

This pattern is yet another variation on model-view-controller and model-view-presenter.

[Tony Marston]

Unless you can explain why the logic for working out the total number of available pages belongs in the model, your argument is void

This whole argument can be boiled down to a difference in the interpretation of what constitutes "display logic". To me it is quite simple:

• Code which transforms data into HTML is display logic.
• Code which creates or obtains the data which is subsequently transformed into HTML is not display logic.

Your implementation may therefore be different depending on your interpretation, but surely different implementations ARE allowed?

[TomB]

I've answered that more than once.

You still haven't explained why it belongs in the model. Whether you class it as display logic or not is irrelevant. Answer this: Why does it belong in the model?

but surely different implementations ARE allowed?

Spaghetti code is allowed it also works. There are, however, obvious disadvantages.

[matthijsA]

Been following the discussion with interest. I can only speak for myself, but my idea would be to focus on the question why a certain way of doing things is better or worse. What drawbacks each way of doing things has. And if possible explain it with simple code examples. Discussing what "real MVC" allows or not and nitpicking the words being used (may/may not/should/should not) in articles explaining MVC probably doesn't help much. At least for me.

There already have been given some small code examples. It probably would help to give some more. For myself, I don't care so much what is "officially allowed" in "real MVC". What is important is the why behind a certain pattern. For example a snippet of pagination code being repeated all over the place instead of having it in one location makes changes hard to make. Or a piece of view logic being reusable. Or a controller method getting too big. Etc.

[TomB]

You are correct, perhaps we are missing the bigger picture here.

I suppose it would be useful to explain why the view has access the model. It has been covered here but it's spread about in many different posts within various contexts.


Without access to the model, the view is reliant on getting its data passed to it from the controller. This puts logic related to interrigating the model into the controller. Controllers are not designed to be reusable.[1][2] (that's not to say they can't be, only that generally they're used to handle one specific job within the application and re-using them implies that your system is doing the same thing in multiple places).

Views are expected to be reused with different models[3][4]. If the controller is sending data to the view, some of this reusability is lost. The controller now contains display logic (which is not re-usable). Pagination is probably the simplest example of this because it's something we all understand, but we've gone over this enough and I've already supplied examples.

Essentially wherever the view needs to make multiple requests to the model, you have to add an extra step to bind the variable to the model to a variable in the view. In an extreme example, you may end up with your controller doing this:

$user = $this->user->find($id);
$this->view->assign('firstname', $user->firstname);
$this->view->assign('surname', $user->surname);
$this->view->assign('address1', $user->address1); 

Of course in a real world scenario the view can probably deal with an array of all these fields, but the principle is the same. Extra, unneccesary, binding logic in the controller. Along with the controller taking responsibilty of querying the model.


The result of this?

-Slower development, you need to add the binding logic

-Harder to maintain code because changes now need to be made in the controller too, to add the binding.

-Potential for inconsitent naming (I've seen cases where, for example, a field is called "last_name" in the model but referred to as "surname" in the view. This simply leads to confusion for anyone looking at the code)

-Potential for binding errors/consistency. Because this logic exists, it removes the contract between the view and the model. This means 'address1' in the view doesn't really represent anything. It can be anything. There's nothing to stop the controller sending the wrong data. (To give some anecdotal evidence, in my last job we had a similar set up (as much as I argued against it), the requirements changed along the lines of "can you remove the address from this page" rather than modify the view one of my colleagues decided it would be a good idea to change the controller to do $view->assign('address', null); Of course when the view was reused elsewhere by another developer, he had to spend time working out why the address was showing on the new page and not on the old one. The controller now inadvertently contained display logic: it was telling the view not to show the address.)

-Poor reusability. In another controller that's using the view I need to create all that binding logic again....


-and when the view is changed (e.g. i add another field), I need to modify every controller which uses the view.

-imagine the requirements change to 'also show the users last order id' on that view. The view could be used in 100 different places. If I need to assign the order from the controller(s) that's 100 files I need to edit (And i need to find out where it's being used!). If the view can request this directly from the model, I need to only modify the view.

[Tony Marston]

You still haven't explained why it belongs in the model. Whether you class it as display logic or not is irrelevant. Answer this: Why does it belong in the model?

It is not display logic because it does not produce any HTML.

It is not display logic, therefore I am not forced to put it in the View.

Because I am not forced to put it in the View I can put it wherever I like. I put it in my DAO because that is where I issue the SQL query and that is the where the data is first available for processing.

There is only one place in my code where as SQL SELECT statement is issued, so it has standard code to produce all the variables that may be used in pagination. This data is displayed slightly differently depending on whether the View is for a single record only, or several records.

[Tony Marston]

Controllers are not designed to be reusable. (that's not to say they can't be, only that generally they're used to handle one specific job within the application and re-using them implies that your system is doing the same thing in multiple places).

My controllers ARE resuable. I link a Controller and a View (XSL stylesheet) to form what I call a Transaction Pattern. I am able to combine a Transaction Pattern with ANY Model to form a working transaction. I can do this because neither the Controller nor the View contains any hard-coded table or field names.

Views are expected to be reused with different models.

As I have said many times over my Views can be reused with different Models.

If the controller is sending data to the view, some of this reusability is lost. The controller now contains display logic (which is not re-usable). Pagination is probably the simplest example of this because it's something we all understand, but we've gone over this enough and I've already supplied examples.

I have no code in any Controller which creates any HTML, therefore no Controler contains any display logic. I have no code in any Controller which has any hard-coded table or field names which are specific to any Model, therefore a Controller can be reused with any Model. I am not losing any reusablity at all.

Essentially wherever the view needs to make multiple requests to the model, you have to add an extra step to bind the variable to the model to a variable in the view.

I do not pass each record around field by field, I use an array. This means no hard-coded table or field names.

The result of this?

-Slower development, you need to add the binding logic

-Harder to maintain code because changes now need to be made in the controller too, to add the binding.

My Views and Controllers were developed once and designed to be reusable, therefore there is no more "development overhead".

-Potential for inconsitent naming (I've seen cases where, for example, a field is called "last_name" in the model but referred to as "surname" in the view. This simply leads to confusion for anyone looking at the code)

I never change field names between what's in the database and what's in the View, so I never have this problem.

-Potential for binding errors/consistency. Because this logic exists, it removes the contract between the view and the model.

-Poor reusability. In another controller that's using the view I need to create all that binding logic again....

-and when the view is changed (e.g. i add another field), I need to modify every controller which uses the view.
-imagine the requirements change to 'also show the users last order id' on that view. The view could be used in 100 different places. If I need to assign the order from the controller(s) that's 100 files I need to edit (And i need to find out where it's being used!). If the view can request this directly from the model, I need to only modify the view.

I do not need to modify the Controller if I change the View. Data comes out of the Model as an array and goes into the View as an array. This array can contain any number of fields, but I never move fields around one at a time, so I never have to know their names.

I do not have these problems you mention, therefore my implementation cannot be as bad as you think.

[matthijsA]

@tomb: thanks for the example and explanation. What you write makes sense.

[sunwukung]

therefore my implementation cannot be as bad as you think.

That a body of code is functional does not of itself suggest that it is elegant, which is where I believe the heart of this issue lies. Sure, the application works, but is it "optimal". Define "optimal". Is that a personal yardstick - is that definition biased towards our own preference/ignorance?

One issue with your argument is that you validate it through anecdotal references to your personal framework implementation, and then go on to posit that as a cardinal point of reference for MVC as a concept.

TomB's argument is presented in such a way that we can percieve it without having to download a copy of TomIgniter, and is therefore standing on firmer ground (as far as I'm concerned.) It's all about presentation...

I suspect you are missing a key point about Tom's argument - which is well illustrated here: http://blog.astrumfutura.com/archive...preciated.html

Essentially, assigning VALUES to the view via the controller binds display logic into the controller. Passing the Model directly to the View on the other hand, and allowing the View to extract what it needs from the Model preserves decoupling and maintains the Model's isolation. People (like myself) tend to see the "view" simply as a template to echo out pre-evaluated variables.

Tom (as I understand it) is proposing that generating HTML from markup extracted from the Model is the true function of the "View" and allows us to decouple components. Taking this a step further, using View Helpers allows us to "widgetize" the Model in the View - a great method of providing AJAX functionality and decoupling the Model entirely from the Controller on it's return journey from the Request.

In our quest for separation of presentation and logic, demoting viewscripts to PHP variable templates is throwing the baby out with the bath water...

[TomB]

My controllers ARE resuable. I link a Controller and a View (XSL stylesheet) to form what I call a Transaction Pattern. I am able to combine a Transaction Pattern with ANY Model to form a working transaction. I can do this because neither the Controller nor the View contains any hard-coded table or field names.


As I have said many times over my Views can be reused with different Models.


I have no code in any Controller which creates any HTML, therefore no Controler contains any display logic. I have no code in any Controller which has any hard-coded table or field names which are specific to any Model, therefore a Controller can be reused with any Model. I am not losing any reusablity at all.


I do not pass each record around field by field, I use an array. This means no hard-coded table or field names.

My Views and Controllers were developed once and designed to be reusable, therefore there is no more "development overhead".


I never change field names between what's in the database and what's in the View, so I never have this problem.


I do not need to modify the Controller if I change the View. Data comes out of the Model as an array and goes into the View as an array. This array can contain any number of fields, but I never move fields around one at a time, so I never have to know their names.

I do not have these problems you mention, therefore my implementation cannot be as bad as you think.

I think that sunwukung hit the nail on the head. Unless you're willing to discuss this in general terms it's pointless. As Czaries said on page two: 'This is not a "my framework design is better than yours" contest'.

Your own framework is not relevant. We are talking on very generic terms here taking things one at a time, not discussing how an entire framework works. I don't believe I've mentioned exactly how I do anything or even specify what my own code can/cant do. It's irrelevant, It's implementation. We are discussing concepts.

Essentially, Tony, It's come to this:

TomB: Idea X is better than idea Y because [reasoning including citations]

Tony Marston: My framework already does Y therefore X is wrong.

Of course that's not to say my reasoning is valid.. but you're not arguing against my reasoning, you're arguing using your own framework as if it's the pinnacle of technology and is right because it already does things. It may well have solved the problems we're talking about. That isn't the issue here, we are discussing the best way to solve the problem, a detail you seem to miss.

[PCSpectra]

Martin Folwer is in fact not discussing MVC there. It's a variant of MVP:

This pattern is yet another variation on model-view-controller and model-view-presenter.

I know Fowler says MVP, but the diagram itself speaks volumes. The components are still labeled Model-View-Controller not Model-View-Presenter. The dependencies are different but the names given to each component remain the same. MVP is more analogous to frameworks like MSMFC implement, not strictly MVC.

In MVP (or at least my interpretation) you build a dialog box and in that dialog box you have several controls (text fields, combobox, etc). Each component of the dialog is not responsible for loading it's contents and thus does not need a controller, so much as a model and a view.

The parent container (typically a dialog or window) will initialize each components data (ie: model) perhaps at OnLoad() or after the selection of a list of available records.

This is a subtle, but distinct difference between MVC and MVP, the presenter (in this case) is responsible for querying the databases, etc and initializing the controls.

This is why I said passive view MVC is better suited for web (and it's request-repsonse cycle) because the view in web MVC is typically dumb, no more than templates are *usually* required to develop complex interfaces.

You provide the template with an array of addresses, phone numbers, etc. The template accepts the arrays and it's basic presentation logic to loop over data and render result and send to screen, repeat.

Cheers,
Alex

[arborint]

If you look at those graphs I think you will see that the important points of MVC (of which MVP is a derivative) exist in all of them (see the arrows). That is -- the Model is in a separate layer and generally independent from the Presentation layer code. As I said above, the differences are mostly about how to divide up responsibilities and dependencies in the Presentation layer. Many of the differences, such as between Supervising Controller and Passive View are differences in the thinking of guys like Martin Fowler over the years (he retired MVP but it still lingers in .NET). All of those ideas can be used by programmers for their implementations.

People can (and do) talk until they are blue in the face about which is their favorite, but it is the basic concepts and possible options that are what we programmers really need to know. The range of patterns from Transaction Script all the way up to MVC are all solutions to problems and useful depending on needs and circumstances.

There are a range of implementation possibilities in MVC. TomB showed the most basic example of Push based Controller code here:

$user = $this->user->find($id);
$this->view->assign('firstname', $user->firstname);
$this->view->assign('surname', $user->surname);
$this->view->assign('address1', $user->address1); 

But other variations are possible, such as passing the Model object to the View:

$user = $this->user->find($id);
$this->view->assign('user', $user); 

Or passing an array of the pertinent Model data to the View:

$user = $this->user->find($id);
$this->view->assign('userdata', $user->getData()); 

And in a Pull based system all this code would be in the View, which would load the Model directly:

$user = $this->user->find($id);
$this->template->assign('firstname', $user->firstname);
$this->template->assign('surname', $user->surname);
$this->template->assign('address1', $user->address1); 

There are pros and cons to all of these approaches. These patterns and this information are all tools to allow us to make implementation choices. Having an understanding of the options and possibilities allows us to make informed decisions.

However, there is also a lot of personal preference in these discussions -- which is why these threads get so long.

[TomB]

This is why I said passive view MVC is better suited for web (and it's request-repsonse cycle) because the view in web MVC is typically dumb, no more than templates are *usually* required to develop complex interfaces.

Well, from an simplicity point of view, it probably is easier to use templates as views and pass them data from the controller (Which is 'Passive View'/MVP, not MVC, but I digress). The problems arise in both reusability and maintainability as I have demonstrated.

That's not to say passing the model to the view doesn't create its own problems: if you take a direct "pass the model to the view" approach, it actually creates a firm contract between a model and a view, which itself causes limited reusability of the display logic. Of course this is easier to fix: separate out the parts related to a specific model and abstract the problem away. Much like the model cannot realistically be represented by a single class neither can the view.

This is actually one of best, yet blissfully ignored, parts of the article "The M in MVC: Why Models are Misunderstood and Unappreciated". He doesn't spend much time on the subject but the idea he presents for view-model interaction is spot on:

"My own thoughts were that Views could skip the middleman and instead use View Helpers to read data from Models more directly. This would support an architecture where in many read-only page requests, your Controller Action would be...empty."

"all Model interaction extracted into simple reusable View Helpers, would reduce code duplication in Controllers (lots of code duplication!) and avoid the necessity of chaining Controller Actions."

People often quote that article in regards to controller taking over model responsibilities, but rarely in regard to the controller taking over view responsibilities, which is a shame. His ideas are sound.


In fact I might have to make this quote my signature:

"It's still tough going just to get anyone to give Views data objects, let alone let them read directly from Models..."

[Michael Morris]

Off Topic:

Give it up guys. Tony is an intellectual narcissist. He's incapable of being wrong in his own eyes.

[PCSpectra]

Haha...I think all passionate developers are, Tony is just a little more assertive about his opinion than some. When it comes to the discussion of best practices, there isn't really a right or wrong, more what is 'best' for a given situation and developer.

Sure there are some general practices which make sense and provide some guidance, but it is clear to me (having spent the last 15+ years) arguing whether I am right and you (as in anyone) are wrong is about as useless as the tits on a billy goat.

That being said, I appreciate anyones comments on best pratice, I have changed my mind/understanding/acceptance of most patterns (MVC especially) so many times I think I have forgotten more than I currently know. :P

My point is, if I argue and debate with myself over best practices and what is right or wrong, I can only imagine how someone other than me feels about my opinions. :P

All I can say about patterns, is learn them as much as you personally feel comfortable, try them, implement them, when things don't feel right, ask around forums about how others would solve the same problem, apply those changes and see if that corrects the 'feeling'. Trial and error, best learning tool I ever discovered.

Cheers,
Alex

[Tony Marston]

Tony is an intellectual narcissist. He's incapable of being wrong in his own eyes.

So I'm just like every other programmer, then, who thinks that his work is brilliant while the work of others is cr*p.

[arborint]

I am a programmer. I consider the work of people like Trygve Reenskaug, Martin Fowler, Eric Evans, etc. brilliant, while I consider much of my own work cr*p. That is while I spend more time trying to understand what they are saying, and less time telling people about my own code.

So there appear to be at least two kinds of programmers...