Page 1 of 2

Thinking MVC

Posted: Sun Aug 12, 2007 2:44 pm
by superdezign
This topic has given birth to this one.

I've never really read much on MVC that gave anything beyond concept, and from there I just went forth and did whatever. Now, I'm seeing code examples that show me that the things I originally didn't see as possible most certainly are. My controllers used to be hard-coded into the files (until today :P), so I'm pretty sure that I'm at least familiar with what the controllers handle.

There was a config file that created the base template, and then the other files would inject content into that template's "Content" section using view objects that were sent to the model objects. So, the files looked like:

Code: Select all

include dirname(__FILE__) . '/config.php'; // $pDisplay is initialized in config.php
include dirname(__FILE__) . '/modules/user/login.php';

$pDisplay->SetStylesheets('form.css', 'user.css');

$pContent = new User_Login(new Template('templates/modules/form.tpl'));

$pDisplay->SetContent($pContent);

echo $pDisplay;
My problem is thinking of the right way to bring this over to an OO controller scheme. After seeing d11's ingenious forward() function, I thought of always sending the front controller through a controller that handled the default view, which would then forward to a controller than held the inner content view. But then that made me think I should just handle it in the front controller. I tried to base the decision on which would allow multiple base templates, but both could.

How is everyone else (that uses an OOP MVC design) doing it?

Posted: Sun Aug 12, 2007 9:06 pm
by s.dot
I'm interested in seeing the replies to this as well. From what I seen in the code posted in that topic you referenced, the echo $pDisplay stands out a bit to me.

Seems like it should be in a method..

Code: Select all

$pDisplay->SetContent($pContent)->dispatch();
Where dispatch() would be in a model class extends controller(). I'm probably wrong here, but I'm learning.

Posted: Sun Aug 12, 2007 11:29 pm
by Christopher
I am not exactly sure what you asking, but I think you are inching into the murky world of the View and Controller/View separation. That is a very big subject.

Then there the subject of building hierarchies. Generally there are hierarchies of controllers and hierarchies of Views. I tend to prefer the latter because I don't find many problems that actually require full Controller hierarchies, and the complexity of getting a good hierarchical Controllers is much more that forwarding which can do some of the same things.

I like to solve the design problems of View hierarchies by sharing duties between the View and Response classes.

Posted: Mon Aug 13, 2007 5:41 am
by superdezign
Yes, I've been studying the MVC approach since my days in C++ and the one thing I always oversimplified was the Controller-View relationship.

From what I understand, the request goes to the controller which has a specific view associated with it. The controller sends the request to the model, the model sends back a response, and the controller uses that data to populate the view, at which point the view is displayed.

Most concepts I've read (though all more suited to one situation than another... Games, desktop applications, websites) give the idea of nested views, which is something that I already used, but my methods made the model a 'controller' of the view when the controller seems to be the one that should control the data being passed between the view and the model. To nest views, one article that I read (on windows applications) suggested that the same way every controller should have a view, every view should have a controller.

So the controller takes the request and creates the view, then forwards the request to a controller with a 'sub-view' that will inevitably become a part of it's parent view. Would this mean that the next controller was invoked as a part of the model, being sent with the model's response data?

Posted: Mon Aug 13, 2007 6:50 am
by Chris Corbyn
superdezign wrote:From what I understand, the request goes to the controller which has a specific view associated with it. The controller sends the request to the model, the model sends back a response, and the controller uses that data to populate the view, at which point the view is displayed.
Model doesn't send any response back. Sending a response is something the controller does. Controllers do usually have a view associated with them, but it doesn't have to be as rigid as you suggest ;) The controller could choose to disable the view, send PDF data instead maybe, or select a different view entirely. Try to be flexible with your coupling between the view and controller. But I assume you're referring only to page/action controllers here.
superdezign wrote:Most concepts I've read (though all more suited to one situation than another... Games, desktop applications, websites) give the idea of nested views, which is something that I already used, but my methods made the model a 'controller' of the view when the controller seems to be the one that should control the data being passed between the view and the model.
Controller does provide a means of getting data between the Model and the View but inexperience often leads people to pass very specific things into the view (myself included if we go back 6 months or so). Ideally you want to pass very loose model data into the View because it's up to the View what it does to display it. There are design patterns which help make the interface for this pretty straightfoward (ORM for one).
superdezign wrote: To nest views, one article that I read (on windows applications) suggested that the same way every controller should have a view, every view should have a controller.

So the controller takes the request and creates the view, then forwards the request to a controller with a 'sub-view' that will inevitably become a part of it's parent view. Would this mean that the next controller was invoked as a part of the model, being sent with the model's response data?
Terminology: Nested Views === Composite View (a design pattern which you may have better luck googling)

I disagree that every controller should have a view. If I run my framework via command line the view layer is skipped completely since all user input is happening in real-time at the controller layer. What about AJAX requests too, you don't want a View for those. I think you need to have a controller-view interaction which allows the controller to say "no view please, I'll just deal with this".

Posted: Mon Aug 13, 2007 1:23 pm
by superdezign
d11wtq wrote:Model doesn't send any response back. Sending a response is something the controller does. Controllers do usually have a view associated with them, but it doesn't have to be as rigid as you suggest ;) The controller could choose to disable the view, send PDF data instead maybe, or select a different view entirely. Try to be flexible with your coupling between the view and controller. But I assume you're referring only to page/action controllers here.
Okay, this is making more and more sense. :)

I know that the model gives data that is used to populate the view and the controller is the middleman for this, which makes it possible for views to be nested (or composite views). The controller takes the request, and sends back a response.. but is this response sent to the calling controller?

One thing that I'm getting as a common-ground from programming language to programming language is that in an MVC approach, there will be multiple sets of MVC's, each communicating with one another through the controllers. I originally though it was simply controller-input, model-data, view-output, but I was missing the communication between that actually makes it useful.

What I'm not quite understanding is what the response is comprised of.. Would the response be the final output of the controller's model-view combination?

If so, then wouldn't I be able to implement composite views by sending back a chain of responses from each controller all the way back up to the front controller, or maybe.. creating a stack within the front controller and having the front controller do all of the forwarding (if that's possible), then compile the final views together?

Posted: Mon Aug 13, 2007 3:31 pm
by Christopher
I am going to quibble a little here:
d11wtq wrote:Model doesn't send any response back. Sending a response is something the controller does. Controllers do usually have a view associated with them, but it doesn't have to be as rigid as you suggest ;) The controller could choose to disable the view, send PDF data instead maybe, or select a different view entirely. Try to be flexible with your coupling between the view and controller. But I assume you're referring only to page/action controllers here.
The Model definitely does not "send any response back". But sending a response is not really role of the controller and should be done by the View or a Response object that post-processes the View in some way.

I think in general you can think of the Controller dealing with the request and the View dealing with the response.
d11wtq wrote:Controller does provide a means of getting data between the Model and the View but inexperience often leads people to pass very specific things into the view (myself included if we go back 6 months or so). Ideally you want to pass very loose model data into the View because it's up to the View what it does to display it. There are design patterns which help make the interface for this pretty straightfoward (ORM for one).
One of the great design questions in MVC is whether the Controller is a go-between for the Model and View, or whether the View can get the Model itself. I think we may want to delve into the issue a little deeper because there is not hard-and-fast rule.
d11wtq wrote:I disagree that every controller should have a view. If I run my framework via command line the view layer is skipped completely since all user input is happening in real-time at the controller layer. What about AJAX requests too, you don't want a View for those. I think you need to have a controller-view interaction which allows the controller to say "no view please, I'll just deal with this".
Techincally any application that generates a response and implements MVC has a View. An XML response to an Ajax call or outputting a PDF would both be done by "The View." In fact, that is the whole point. An application can have multiple "views" of the same domain information (Model) so that the same Model/Controller can respond with HTML, XML for Ajax, PDF, etc.

Posted: Mon Aug 13, 2007 3:33 pm
by Chris Corbyn
I agree on all counts :)

Posted: Mon Aug 13, 2007 3:41 pm
by kyberfabrikken
arborint wrote: Then there the subject of building hierarchies. Generally there are hierarchies of controllers and hierarchies of Views. I tend to prefer the latter because I don't find many problems that actually require full Controller hierarchies, and the complexity of getting a good hierarchical Controllers is much more that forwarding which can do some of the same things.
Very nicely put. The view is where you need a hierarchy. If you want to maintain a high separation of view and controller, it would then follow that you either 1) have two parallel hierarchies or 2) a flat controller layer and only use a hierarchy in the view layer. Personally, and where I'm going with Konstrukt, is to have a more tightly coupled relationship between view and controller. That way, a single hierarchy can be used as a skeleton for both layers. The trade off is then, that I lose full V/C separation. Since most web applications have just one (primary) output type (HTML), I'm confident with this limitation. Do you actually use V/C separation in practise?

Posted: Mon Aug 13, 2007 3:49 pm
by superdezign
arborint wrote:The Model definitely does not "send any response back". But sending a response is not really role of the controller and should be done by the View or a Response object that post-processes the View in some way.

I think in general you can think of the Controller dealing with the request and the View dealing with the response.
:-D Well then that actually seems a LOT more workable. Okay, okay. ^_^
arborint wrote:One of the great design questions in MVC is whether the Controller is a go-between for the Model and View, or whether the View can get the Model itself. I think we may want to delve into the issue a little deeper because there is not hard-and-fast rule.
I was playing around with that myself and so far, it feels as though the controller does it, but the data is actually being sent straight to the view. The controller is just the one that actually does the sending, so the model and view don't have direct access to one another and couldn't communicate without the controller.
arborint wrote:Techincally any application that generates a response and implements MVC has a View. An XML response to an Ajax call or outputting a PDF would both be done by "The View." In fact, that is the whole point. An application can have multiple "views" of the same domain information (Model) so that the same Model/Controller can respond with HTML, XML for Ajax, PDF, etc.
Whew, okay then. Everything I had read said that it was possible to 'skip' the model, but not the view or controller. Like, a form, in it's simplest form, is just VC, where it takes user input and does nothing to it other than displaying it. It isn't until form processing comes into the picture that the 'M' slips it's way in there.


I've already got my requests and such working very well, responses were the only thing I was having trouble with. So the response *is* the 'final result' of each MVC set, right? So I'd start at my front controller, send a request to my action controllers that all send their requests (if any), and then return their responses in the order that there requests were sent.

Ooh, but then, would the response object technically become a part of the model at that point (not the actual module, but like.. the 'M' :P)?

Posted: Mon Aug 13, 2007 3:55 pm
by Christopher
superdezign wrote:I know that the model gives data that is used to populate the view and the controller is the middleman for this, which makes it possible for views to be nested (or composite views). The controller takes the request, and sends back a response.. but is this response sent to the calling controller?
The Controller can be a middleman, but the View can also load the Model directly. One key to MVC is that it is three things in two layers: the Model is in the domain layer, the View and Controller are in the presentation layer. That means the the layer separation is first and most important, the separation between the View and Controller is fuzzier. But remember the relationship between the Model and View, and Model and Controller is the same layer separation.
superdezign wrote:One thing that I'm getting as a common-ground from programming language to programming language is that in an MVC approach, there will be multiple sets of MVC's, each communicating with one another through the controllers. I originally though it was simply controller-input, model-data, view-output, but I was missing the communication between that actually makes it useful.
Typically the "multiple sets of MVC's" implementation adds complexity. It can be necessary is some cases, but much more common is the Composite View solution which only has "multiple sets of MV's". It is in some ways only a conceptional difference because of the fuzziness between what is Controller stuff and what is View stuff, but you have to think of it -- implementation-wise -- in relation to the Front/Action controller architecture that often accompanies MVC.
superdezign wrote:What I'm not quite understanding is what the response is comprised of.. Would the response be the final output of the controller's model-view combination?
The response can have a couple responsibilities. It often has data associated with it (Response Model) such as character encoding or meta data. It deals with redirects in web apps. It is also often the root node of the View tree.
superdezign wrote:If so, then wouldn't I be able to implement composite views by sending back a chain of responses from each controller all the way back up to the front controller, or maybe.. creating a stack within the front controller and having the front controller do all of the forwarding (if that's possible), then compile the final views together?
First, the Front Controller only sorts out it's portion of the request and dispatches. It really just launched the MVC thingy. Usually the View aggregation that you are talking about happens after the Front/Action Controller returns.

Posted: Mon Aug 13, 2007 4:06 pm
by superdezign
arborint wrote:The Controller can be a middleman, but the View can also load the Model directly. One key to MVC is that it is three things in two layers: the Model is in the domain layer, the View and Controller are in the presentation layer. That means the the layer separation is first and most important, the separation between the View and Controller is fuzzier. But remember the relationship between the Model and View, and Model and Controller is the same layer separation.
So, that would be like all of the "Business Logic -> Document View" stuff I've been reading about, where they say it's basically MVC, but they compress the VC together as the "Document View?"
arborint wrote:Typically the "multiple sets of MVC's" implementation adds complexity. It can be necessary is some cases, but much more common is the Composite View solution which only has "multiple sets of MV's". It is in some ways only a conceptional difference because of the fuzziness between what is Controller stuff and what is View stuff, but you have to think of it -- implementation-wise -- in relation to the Front/Action controller architecture that often accompanies MVC.
8O That what I used to do! Started with the controller, and then just went from model to view to model to view directly... That's what all of those articles on composite views were saying? I thought the controller was there, but they just weren't mentioning it.
arborint wrote:First, the Front Controller only sorts out it's portion of the request and dispatches. It really just launched the MVC thingy. Usually the View aggregation that you are talking about happens after the Front/Action Controller returns.
That makes sense. I feel like I get it, but I've gotta write it all and make sure. ^_^

Posted: Tue Aug 14, 2007 7:26 am
by superdezign
I'm not sure if I'm doing this correctly, but it seems like it.

The controllers don't each create a separate request or a response; I create a Request object and a Response object, and these are sent to the front controller. The front controller forwards these objects to the action controllers which use the Request to control their models, send the model's data to the view, and then append the view to the Response object. After all of the action controllers have appended their view objects, the Response object processes each of the view nodes and then outputs the result.

I think I've got it, though I'm not completely sure. I do know that it's actually working though. ^_^

Posted: Tue Aug 14, 2007 8:20 am
by McGruff
the model and view don't have direct access to one another and couldn't communicate without the controller.
MVC refines the standard presentation / domain / data access layering by splitting the presentation layer in two: view and controller. Presentation objects are free to roam across the domain and so there's no reason why objects from the view layer cannot access domain objects, requesting whatever information they need to create a screen. The only condition is that they must be read-only. Only the controller is allowed to manipulate the domain.

View objects may also passively observe the domain.
superdezign wrote:send the model's data to the view
Controllers do not mediate between model and view as was mentioned in an earlier post. Objects in the controller layer should not pass data to the view.

You'll need a separate assembly layer to keep the two apart (it's the absence of this which forces you to instantiate everything in the controller and then pass stuff on to view objects from here). A hard-coded factory to wire up the object graph is a good place to start. Phemto is nice if bits of that need to be configurable.

But why do you want an MVC architecture in the first place?

Posted: Tue Aug 14, 2007 8:36 am
by superdezign
McGruff wrote:But why do you want an MVC architecture in the first place?
PHP in HTML... HTML in PHP... It was all too messy for me. I've had a basic MVC for about a month now, but the controllers were hardcoded as pages, and the modules and views were merged into one element. The separation to that much was much neater than previous but getting closer a pure MVC structure is proving to be even more manageable. It's just a matter of "doing it properly" at this point.