MVCP - MVC missing a layer?

[McGruff]

An http request could maybe be seen as having two parts.

(1) a "presentation request" - ie the page to serve up to the client (model and view)

(2) a "processing request" - any tasks which do not output anything to the browser: form processing prior to building the "success" page/form redisplay, authentication, etc (added in controller)

In addition to MV&C, I wonder if there should be an explicit "non-output-processes" layer? That feels more symmetrical, putting non-output-tasks on a par with model & view in the API. Quite often there are questions about where in the MVC model form-processing should go - maybe this would make it clearer.

Any takers for MVCP?

[sweatje]

IMO that is just an action of the controller, and specifically one from which you would send a redirect to an action that would show a view (sucess, errors, etc.).

[mr tinkles]

An http request could maybe be seen as having two parts.

or many!

but, a http request, is merely http request, or 1 part. http request.

[lastcraft]

Hi...

Any takers for MVCP?

In three years of tackling these issues I have not once managed to understand how MVC applies to the web. I have read the Model-View-Presenter stuff as well (which seems closer to what is now called MVC, rather than the original Xerox-PARC stuff). Sadly, I am still none the wiser .

I cannot resist tossing in my own half baked ideas to date...

Firstly this has nothing to do with templates. The view may use templates or it may not. The template may dictate (with custom tags) the domain code that gets executed and so may be more than just a view. Templating is mostly orthogonal.

This has nothing to do with handling user input either. We get a dash of input before the script even gets run, but after that human intervention (except the stop button) is impossible. It is basically a batch process. To make matters worse the chosen script and the incoming data don't necessarily match up. We have to fix this to match the view with the data. After that we are locked into some kind of TransactionScript. The front controller gets around this by having only one script as an entry point.

The model is not the same as the database. Because PHP starts empty on every request, only persistent information and network accessable information is available. This makes the model much more clearly defined than in, say, Java. However, we can cloud the issue by saving sessions out to the database. Session information is nothing to do with the model though, and should be kept conceptually separate. Thus the database may be involved in the controller/view system or the model.

Simplistically it strikes me that the "controller" in web MVC is actually just internal logic to stitch together the incoming arguments to the script that will run them. It has absolutely nothing to do with the controller in GUI apps. Except, there is more to it than that.

The "web application" is an illusion created by a sequence of scripts. To maintain that illusion we have to have some kind of super controller to manage the steps. This step controller doesn't usually exist in any single script. Because in PHP we are always completing the last action and offering up the next, we are actually doing two half jobs. This means that the real application control, the real top level meat, occours half way between each script. A good way of exposing it is to split all top level scripts into *_display.php and *_handler.php in a typical application. You suddenly find that you need a bit of extra logic either at the end of the handler script, or the start of the display script to select the next display. Hardly surprising that this very important top level logic gets buried away and becomes difficult to modify. I wouldn't call the class that deals with this logic a "controller". More of a "navigator".

The real killer is that different parts of the app. need different styles. A library site needs static URLs with multiple views. A bulletin board is highly dynamic form based environment and would favour a FrontController regime. A shopping cart needs a "navigator" type of controller as this is more of a "Wizard" interface. Trying to fit all of these into MVC strikes me as way too difficult.

And I still don't understand MVC...

yours, Marcus

[McGruff]

Very interesting.

MVC RIP, I guess

[raz0]

Very good post there lastcraft. You keep amasing me.

[ghurtado]

Lastcraft, always a Prophet. You got my own gears turning as well...

[lastcraft]

Hi...

Amazing. I can spout junk off the top of my head and admit I don't even understand the problem, and people love me . Cool .

Guys, I really don't know what I am talking about here. I am probably more confused than anyone and all I see is problems and no answers. It needs a Jason or a Jeff to sort out my mess of a post.

yours, Marcus

[sweatje]

Too busy putting the final touches on the presentations for the cruise presentations to go in depth at the moment, but your comment and the responses remined me of two quotes:

True knowledge consists of knowing that you know nothing.

and

Knowing what questions to ask is half the battle.

Can I recommend downloading PHP|Architects free (with registration) issue that has my "Introduction to MVC using PHP" article and "Industrial Strength MVC" for some of my opinions on MVC.

Regards

[Dr Livingston]

I've always thought that MVP was all ******** anyways

--EDIT--

I've been sensored...

[Azmo]

For those of you who haven't read it yet: Beyond MVC: A New Look at the Servlet Infrastructure.

N. Alex Rupp makes a good case against using MVC outside it's original context (applications with user interfaces). The only thing I'm not entirely happy about is the alternative application 'structure' he suggests on page 3: it's possible to perform an Action that doesn't use any DataSource or WorkFlow components, so mentioning these the explicitely may suggest to some people that they must be included for each possible Action.

To be honest, I find it a bit surprising that so many people on these forums are still trying to use MVC, when the pattern raises so many questions about application structure and layering, the placement of concerns, etc. Just look at all the threads about the location of SQL queries, form validation, etcetera. And as far as I can tell, most (if not all) of these problems still have to be solved by the people who originally submitted them, so it doesn't look like the MVC pattern is really solving any problems...

Maybe it would help if we view our PHP scripts as web services instead of web applications: an application is usually associated with direct user interaction, and this direct interaction simply doesn't exist with PHP scripts (unless you're working on a PHP-GTK application, of course).

I tried to use MVC for my PHP framework for some time, and finally decided to move away from it a couple of months ago; it just didn't solve any of the problems I had, and caused me a lot of headaches. Nowadays I'm working with the idea that the total of the client software, server software, and the scripts running on the server all form a single service to a user, where each type of software forms a separate layer, which provides a specific subservice... (basically my own interpretation/visualization of the HTTP protocol).

I'll post a longer description if anyone is interested, and when I have a bit more time.

[Mandibal]

Isnt the the idea of MVC supposed to promote modularity in applications allowing them to use multiple interfaces? I'm not sure I'm wholly disagreeing with all of Marcus' points but I think if you truly seperate the View in your application (even with PHP as your language [and this is where i may be wrong]) you should be able to use a web interface, a gui or even the command line right? This is MVC from my understanding. And this would apply to the web.

[Mandibal]

Azmo brings up some good points as well. Still standing by my previous post and interpretation of MVC but...Maybe a different view is called for which consists of Presentation layer,Domain/Business logic, Business/Data Model. This is from PoEAA. (mostly. Didnt have it in front of me to reference but I think its right). This seems like a better way to look at applications (particularly web) than just MVC.

[MikeShank]

I'm interested in seeing your aprroach

I'll post a longer description if anyone is interested, and when I have a bit more time.

[ghurtado]

Azmo: I too would be very interested what your "post-MVC" world looks like.

While our framework at work is far from a "true" MVC model, I have found that many of the principles that I learned through MVC do apply very well on the web. Most notable of which is probably to separate a view, and more specificially, a "TemplateView" kinda layer. For us, following MVC as a loose guideline (more than as a Bible) has been helpful in more than one ocasion. I still like the principle of a "controller" page as your main entry point and switchboard.

By the same token, violations of some MVC principles that some people hold very dear, have also benefited us greatly, and I plan to continue doing so as long as it makes sense. For a quick example: most MVC uber-zealots would probably tell you that your views have to be 100% "dumb" and in some cases should only accept data through a "push" methodology. I wholeheartedly disagree with this principle, and I foresee a better MVC wherever you add some more responsibilities and capabilities to your templates in the way of components (ala WACT) or other declarative syntax. Its the only good thing that Cold Fusion ever brought to web development: clever templates

[lastcraft]

Hi...

...but I think if you truly seperate the View in your application ... you should be able to use a web interface, a gui or even the command line right?

Absolutely . I have no trouble separating the view from the model. All you have to do is to try to imagine a web version, web services version and command line version. Anything common to all ends up in the model and so a refactoring we go. This pattern used to have a name too - Document/View. This was the pattern adopted for Windows apps. because the old Smalltalk controller functionality, mouse clicks and the like, was now handled by the Windows OS itself. The old controller had very little purpose.

It's the controller that is the problem.

yours, Marcus

[ZangBunny]

Some of the quizzicalness of this thread sounds to me like noone has read PoEAA around here. If you did and you still need help, I'll be happy to play the A-Team. (If you didn't and are too stingy to buy the book, you're on your own. ;-))

[lastcraft]

Hi...

If you did and you still need help, I'll be happy to play the A-Team.

I'll take you up on that . Please explain it all...

yours, Marcus

[Dr Livingston]

This could be interesting huh ? ... Enlighten us all ZannyBunny

[brainpipe]

I'd definitely like to hear ZB's comments, but before he chimes in, I'll add my clutter to the mix. I've seen a few common problems with PHP developers and MVC (and keep in mind that I'm not talking about the contributors to this discussion, rather about common issues I've seen over the last year or so):

1. An almost complete lack of understanding of what MVC is and isn't. There seems to be a push to implement "everything Java" in PHP, and I think that's a mistake. PHP is not now and hopefully never will be Java. I've said it before and I'll say it again: we'd all be better off applying this effort to PHP innovation, not Java duplication. (Which is not to say some Java practices aren't applicable -- many are.) MVC can be useful in PHP web applications, imo, but I get the impression that a lot of developers are tackling it because it's the Latest Buzzword, and they're not taking the time to learn what it is. MVC is a pattern used to separate model from presentation and controller from view, to use Fowler's description. I won't go further because it would all just be more repeat of PoEAA, Pragmatic Programmer, or Core J2EE Patterns (all of which I highly recommend).
2. An almost compete lack of understanding of when and why to use a Front Controller (which I think most developers seem to think is the whole of MVC). There's almost no need for it (imo) in smaller web applications, because you can do an effective job of separation without it, and FC always complicates the code. In smaller web apps, the Page Controller does the trick nicely.
3. For those that do seem to understand the what and when, the most common stumbling block I've seen is the concept of a single controller handling all communication between objects (always makes me think of the multi-armed mail sorter in MiB2). I'm exaggerating, but only a little. From The Pragmatic Programmer:
   

   Each of these views may have its own controller.

   From PoEAA:
   

   The classic example of why you'd want to separate them is to support editable and noneditable behavior, which you can do with one view and two controllers for the two cases, where the controllers are strategies [Gang of Four] for the view.

   Many developers seem limited to only the Front Controller, and they end up attempting to force it to control the entire application, eventually producing spaghetti code. The FC is a router or handler that should appropriately dispatch requests to the proper controller objects, what Fowler calls commands:
   

   Remember that both the handler and the commands are part of the controller. As a result the commands can (and should) choose which view to use for the response.

   And here I've gone and done it -- I'm down to just quoting books after all. <sigh> I suppose I should shut up now.

[mwmitchell]

be interested in seeing how you 'bind' the output of multiple 'MVC' results, to one object. I mean if you have a command that handles a login, a command that handles a search, and a command that handles a message form, all on the same page.... What do you do to bind them all together, to the same view, without all of them knowing about the existence of the other. This is where I stumble.

Matt

[brainpipe]

In that case I'd have an object to handle login, search, etc. The FC dishes off the request to the appropriate command (controller), which then requests the necessary processing and responses from appropriate model objects. Based on the responses from the model, it determines which view is needed and passes appropriate data to that view.

Edit:

In other words, I wouldn't have a login command, I'd have (for example) a UserController command that looks at the request, sees it needs to check the login and get search results, calls the Login and Search objects appropriately, and does what it needs to with the responses.

Also, on the authorization: you may want to simply use an authorize() method in each controller; for restricted access areas, make a call to the appropriate auth object and return that response; for non-restricted areas, just return true. I'm not at all sure this is the best approach, but it does work well. As long as the actual auth logic is separated in an auth (or user) object, the core code doesn't get duplicated, but the access-level security stays where it belongs, in the controller. (It could easily and sometimes rightly be argued that the security belongs in the view, but this, I think, is quite a different topic.)

Edit:

I just realized there's a discussion going on about the topic of authorization in view vs. controller here.

[ZangBunny]

I cannot resist tossing in my own half baked ideas to date...

Welcome to the club!

Firstly this has nothing to do with templates. The view may use templates or it may not.

Heavy nodding up to here.

The template may dictate (with custom tags) the domain code that gets executed and so may be more than just a view. Templating is mostly orthogonal.

It could, but then it wouldn't belong in an MVC architecture. In a clean MVC only the controller can nudge domain code into execution. It then collects the domain objects that result from the logic and hands them off to the view for display. The view should strictly speaking do nothing more than use getters on the domain objects and put their data into the right template variables (if you use one).

This has nothing to do with handling user input either. We get a dash of input before the script even gets run, but after that human intervention (except the stop button) is impossible. It is basically a batch process.

So is any GUI application. The application sits idle waiting for a widget being fiddled with, then it does whatever the user said he wanted. Although it may be very fast, the user usually has to wait until that piece of processing is done. He can put more events into the execution queue, but only rarely can he really intervene in a running piece of logic.

To make matters worse the chosen script and the incoming data don't necessarily match up. We have to fix this to match the view with the data. After that we are locked into some kind of TransactionScript. The front controller gets around this by having only one script as an entry point.

Chosing the correct view is the job of the Controller (which can be a Page Controller, Front Controller, or any other unnamed piece of code). The business logic that gets run before this happens can be anything from a Transaction Script to some Commands on a Domain Model.

The model is not the same as the database. Because PHP starts empty on every request, only persistent information and network accessable information is available.

In most applications the model will rely on some form of persistent data, be it from flat files or a database, because PHP applications do not retain their state between requests.

However, we can cloud the issue by saving sessions out to the database. Session information is nothing to do with the model though, and should be kept conceptually separate. Thus the database may be involved in the controller/view system or the model.

Very cloudy indeed. I would like to think that most of the time the data that is persisted in the session (database or otherwise) belongs to objects that are part of the Model, except for configuration data. I'm open to argument here, though, as there are many things that can be done with session data.

Simplistically it strikes me that the "controller" in web MVC is actually just internal logic to stitch together the incoming arguments to the script that will run them. It has absolutely nothing to do with the controller in GUI apps.

Beg to differ again. The controller in a GUI application receives user input, decides what domain objects need to be instantiated and what commands to be run on them, and then passes the results on to the GUI for display. Same thing.

The "web application" is an illusion created by a sequence of scripts. To maintain that illusion we have to have some kind of super controller to manage the steps. This step controller doesn't usually exist in any single script. (...) I wouldn't call the class that deals with this logic a "controller". More of a "navigator".

This is one point that causes a lot of confusion about MVC: The piece that you are talking about is what Fowler calls an "Application Controller": A layer that controls the flow or sequence of screens that are presented to the user, to be used whenever it gets more complex that one view for one controller. He also says that it has nothing to do with the "Controller" in MVC which he prefers to call "Input Controller". I think this distinction serves a lot to clarify the MVC.

The real killer is that different parts of the app. need different styles. A library site needs static URLs with multiple views. A bulletin board is highly dynamic form based environment and would favour a FrontController regime. A shopping cart needs a "navigator" type of controller as this is more of a "Wizard" interface.

Again, see the above distinction: Where the Front Controller would take the part of MVC's Input Controller, the "Navigator" role is taken by an Application Controller. The two can happily coexist. In my applications the Application Controller is actually used by the Front Controller. After the domain logic is run, control is handed over to the Application Controller who decides what view should be shown next. Before I read PoEAA, I called this part the "Workflow Engine".

Trying to fit all of these into MVC strikes me as way too difficult.

MVC is all about separation of responsibilities. Once you have a clear view of the roles in MVC, it's quite easy to find the right place for each piece of behaviour you need. It helps if you remind yourself that the three letters stand for parts of the application, not individual classes. There will rarely be only one "Controller" or "View" class. The Controller of our last app consisted of almost 20 classes working together to fill the roll.

So there's plenty of space to fit all these things into.

And I still don't understand MVC...

I don't claim I do either, but from looking at it I've gleaned a way to build systems that solve my problems, which is what patterns are all about, after all...

[sweatje]

Very cloudy indeed. I would like to think that most of the time the data that is persisted in the session (database or otherwise) belongs to objects that are part of the Model, except for configuration data. I'm open to argument here, though, as there are many things that can be done with session data.

I agree with ZangBunny on this point. I often bind an array key of the $_SESSION array to a class var in some of my model classes. This effectivly makes the class a singlegton from the perspecitve of that data, as well as allowing the data to persist for the session. Examples of the kinds of situations where I do this include user validation (where the User class maintains the authenticated user id in the session) and Form Wizard type classes where I want to remember user inputs( in case validation fails or the user goes "back" to a form, etc.). (BTW, I make these Form Wizard type classes as models instead of controller objects because of my perspective that $_SESSION data represents a persistant data store, and data stores should be accessed only through the model layer in MVC, if I had a different opinion on the session, I guess I might argue that these Form Wizard classes relate only to $_REQUEST data and should be in the controller instead )

[lastcraft]

Hi.

Ok, if you are A-team I'll be B-team...

It could, but then it wouldn't belong in an MVC architecture.

Quite. I wasn't onto the MVC bit at that point. The custom "smart" tag approach is my current favourite way to do things for complex applications. I think it is a valid pattern in it's own right, a sort of template/tag/model pattern, that is rarely considered. Anyway, digression over.

In a clean MVC only the controller can nudge domain code into execution. It then collects the domain objects that result from the logic and hands them off to the view for display. The view should strictly speaking do nothing more than use getters on the domain objects and put their data into the right template variables (if you use one).

Why? This made sense in the Smalltalk environment which dealt with much more primitive situations. In the enterprise I would have the controller select the view and know nothing at all about the domain. I see no reason for the controller to see the domain as the domain here is likely to be exceedingly complex.

So is any GUI application. The application sits idle waiting for a widget being fiddled with, then it does whatever the user said he wanted. Although it may be very fast, the user usually has to wait until that piece of processing is done. He can put more events into the execution queue, but only rarely can he really intervene in a running piece of logic.

It's not really the same. Firstly there is the scale question. With a GUI we are usually dealing with very fine grained operations that would be tedious over a network. Secondly, long processes can be handled concurrently and can be cancelled in response to the constantly updating view. With the web we usually only get to see things after they are complete.

The real difference though is that the controllers in a GUI app. both present the button and hand off the results of the click. With PHP the whole controller is ripped to bits at the end of the presentation process. Then the session starts another page and we have to find out what controller we were using so that we can finish the request. This adds an enormous amount of complication to what would otherwise be a simple piece of code. That extra rebuilding step is the tricky bit and the one that is not addressed in GUI MVC. I think this is why MVC is not so helpful.

The business logic that gets run before this happens can be anything from a Transaction Script to some Commands on a Domain Model.

This doesn't hold up. If you have just come from a form then that form data will have to be dealt with before anything else. As this data came from a view, then this view will have to be found. This means that the initial order will be control logic, view (to parse the data) and then model. Otherwise you have to introduce more objects. The result of the model interaction will be a result, either success or an error. Some more control logic can then decide the next view.

Even without a form you could be using a clients previous history to decide the next view. The initial start up is still control, view, model.

Very cloudy indeed. I would like to think that most of the time the data that is persisted in the session (database or otherwise) belongs to objects that are part of the Model, except for configuration data. I'm open to argument here, though, as there are many things that can be done with session data.

To me the current state of a shopping basket is a property of a view as it would only apply to a web interface. In fact the Basket itself would probably not exist in the database except when gathering usability statistics. It would become a Purchase at the end of the transaction.

Beg to differ again...

So do I . I was leading to the "Presenter" part of the argument.

The piece that you are talking about is what Fowler calls an "Application Controller": A layer that controls the flow or sequence of screens that are presented to the user, to be used whenever it gets more complex that one view for one controller.

Absolutely. I wanted to avoid the Fowler terminology because he uses the word "controller" for everything. I wanted to avoid "Presenter" because of it's previous use in Smalltalk frameworks. Thus I went for "Navigator", but yes that is the core idea. If you call it a controller though, then MVC has to become MVCC.

The two can happily coexist. In my applications the Application Controller is actually used by the Front Controller. After the domain logic is run, control is handed over to the Application Controller who decides what view should be shown next. Before I read PoEAA, I called this part the "Workflow Engine".

Me too . I called mine "SiteMap".

So there's plenty of space to fit all these things into.

I think that this is the problem. The view and model are easy. Calling everything left over a "controller" doesn't really help. In fact it just seems to slow everybody down. FrontController, TemplateEngine, CustomTag, SiteMap/WorkflowEngine (I won't use ApplicationController within this thread ) and TransactionScript are very clear and powerful design decisions.

The debates on the PHPPatterns site about the FrontController v. the PageController was easy to follow and advanced the issue. The endless MVC discussions don't seem to go anywhere. Even Fowler devotes only a half page to it in the whole book.

MVC is either just an option of many, or it's a unifying concept that covers all of the above. If it's the former then there are better descriptions available and if the latter then it's pretty useless anyway.

...I've gleaned a way to build systems that solve my problems, which is what patterns are all about, after all...

It certainly says in no uncertain terms to separate out the M and the V. I agree this is very helpful.

Sorry about the length of this reply Jochen , It's just that I feel we are getting somewhere .

yours, Marcus