MVC dependencies
-
I wouldn't say it's a problem, but it's not ideal, when you could implement MVC and having the controller handle the dependencies?
I finally got a job doing something I enjoy and I"m good at...15 hour days seem like play time :P
I'm not sure i'd ever want the controller handling all the dependencies... I mean, the whole point of the view is to indicate the current state of the model in some fashion; if you make the view pull this state from the controller, then now you've turned your controller into some sort of proxy-model, and probably added more dependencies between the controller and the model. And since changes to the model need to be communicated somehow to the view, you've just complicated that as well.
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
I'm not sure i'd ever want the controller handling all the dependencies... I mean, the whole point of the view is to indicate the current state of the model in some fashion; if you make the view pull this state from the controller, then now you've turned your controller into some sort of proxy-model, and probably added more dependencies between the controller and the model. And since changes to the model need to be communicated somehow to the view, you've just complicated that as well.
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
I think where we are differing is the environment were working under...the fact you made this statement:
Shog9 wrote:
I mean, the whole point of the view is to indicate the current state of the model in some fashion;
Suggests you are working in a event driven environment like Windows??? Remember, PHP primarily uses HTTP which is stateless, so I am not sure the same mechanisms apply in seperating MVC components... For instance, consider the following: 1) User clicks a HTML button - the browser acts as the client side controller (unless JS is used) 2) Server side script invoked - front controller dispatches to action controller 3) Action controller invoked - Does it return HTML or delete a file - or both? 4) Delete file - Model has been invoked 5) Return HTML to browser (Success or Failure) So you see, in this instance, why would the View need to know of the model as the action controller would simply need to Push/Pull on the Model and then the View? This way Model and View remain free of dependencies? I realize it works different in a Windowing environment, like MFC development, but thats exactly what I'm trying to figure out :P
I finally got a job doing something I enjoy and I"m good at...15 hour days seem like play time :P
-
I'm missing something... RoR is web-based like PHP...but RoR is a strict MVC implementation so I believe? Maybe it's my implementation...but how/why does your view need to be aware of the model? Why can't your controller instantiate the Model and View and pass the View the Model data? This way you keep the Model and View entirely independent (which is the primary goal behind MVC anwyays isn't it?).
I finally got a job doing something I enjoy and I"m good at...15 hour days seem like play time :P
Hockey wrote:
Why can't your controller instantiate the Model and View and pass the View the Model data?
Because, (if i understand your suggestion correction) this would turn the whole pattern on its ear! ;) Think about it: the model is what's actually important. The model is determined by external factors - business rules, time of day, the architect's intentions for the system... making it dependent on the controller now forces the controller into a very, very odd role. Let's look at a very simple example: a push button. The model for this button is very simple; it has a description (let's say a bit of text), an area of the screen that it occupies, and a state (pushed / not pushed). The view is concerned only with rendering this description and state: there are probably thousands of different ways to do this, but for our example we'll do the standard etched line surrounding an area of the screen, in which the button text is displayed. Now, the controller. When the user clicks a mouse button within the area of the screen used by the button, the controller detects this and updates the model state: the button is now pressed. The model notifies the view, which proceeds to draw the button with a different etched line. And that's it. The controller need know nothing about the view, the view needs no knowledge of the controller. Both work entirely off of the model. If a fancier button were designed (say, a button shaped like a star...) then the model might be modified to contain a non-rectangular area, the view modified to draw such an area, and the controller modified to detect only clicks inside this non-rectangular area. But they all still have the same essential responsibilities.
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages
-
I think where we are differing is the environment were working under...the fact you made this statement:
Shog9 wrote:
I mean, the whole point of the view is to indicate the current state of the model in some fashion;
Suggests you are working in a event driven environment like Windows??? Remember, PHP primarily uses HTTP which is stateless, so I am not sure the same mechanisms apply in seperating MVC components... For instance, consider the following: 1) User clicks a HTML button - the browser acts as the client side controller (unless JS is used) 2) Server side script invoked - front controller dispatches to action controller 3) Action controller invoked - Does it return HTML or delete a file - or both? 4) Delete file - Model has been invoked 5) Return HTML to browser (Success or Failure) So you see, in this instance, why would the View need to know of the model as the action controller would simply need to Push/Pull on the Model and then the View? This way Model and View remain free of dependencies? I realize it works different in a Windowing environment, like MFC development, but thats exactly what I'm trying to figure out :P
I finally got a job doing something I enjoy and I"m good at...15 hour days seem like play time :P
Hockey wrote:
Remember, PHP primarily uses HTTP which is stateless, so I am not sure the same mechanisms apply in seperating MVC components...
There are still events; there's just a bit of difficulty with regard to state! ;)
Hockey wrote:
- User clicks a HTML button - the browser acts as the client side controller (unless JS is used) 2) Server side script invoked - front controller dispatches to action controller 3) Action controller invoked - Does it return HTML or delete a file - or both? 4) Delete file - Model has been invoked 5) Return HTML to browser (Success or Failure)
Ok, so let's say the system here is a file manager. The model includes the filesystem, which has a huge amount of state information, but specifically: that a file exists, and that certain permissions apply to it. But there's another part of the model that contains certain user-specific state information (given that there is HTTP sitting between the user and a big part of the system, there are certain things that have to happen for this state information to be correctly associated with the user... but they aren't relevant here). This state information includes, out of necessity, any pending errors that need to be displayed to the user. Now, the view is responsible for displaying this state to the user. Some of this happens server-side (HTML is generated to list the file, any relevant information for that file, and a button for deleting it - if deletion is possible) and some of it happens client-side (actually rendering the HTML). The controller kicks in (as you noted) when the button is clicked: a request is sent back to the server, which processes this request and updates the state of the model (filesystem). Now, because of the limitations of the system, it is possible that another user has locked the file between the view being rendered and the request being sent: in this case, the model will reflect the request's failure. Either way, the view is notified of a change, and proceeds to render it (by producing some HTML and returning it in the response. Note that the model need not care that the view must be rendered every time a response is sent; it still notifies the view that something has changed, as the view might otherwise cache its responses. The controller and the view are linked, in so far as every request made of the controller would require the view to render itself - but even this link might be dissolve
-
Am I wrong or does MVC have different dependencies when developing in an event based environment as opposed to a request/repsonse? While tinkering with MVC (PHP based) I have noticed that I can successfully keep dependencies out of the View and the Model having the controller manage both. Yet, I have read articles where it is suggested otherwise...my impression has been as follows: Event based development, like Windows applications: 1) User clicks button 2) Controller updates the Model 3) Model notifies the Controller of changed state 4) Controller notifies View 5) View pulls on Model I have read a few articles which "suggest" optional dependencies between each component of the triad...when really...I fail to see why the Controller can't simply handle dependencies - as it's basically the wiring that pulls the Model and View togather anyways. When building a web based applications...when would the view ever need knowledge of the model...the way I see it...the controller pulls on the model and passes that data to the view...or simply just pulls on the view or the model... Model and View have zero knowledge of each other...dependencies are centralized in the controller and I can't complain - despite my possibly doing something against traditional accepted MVC practices... Comments?
I finally got a job doing something I enjoy and I"m good at...15 hour days seem like play time :P
Hockey wrote:
- Controller notifies View
Not in my world. :) Controllers and views shouldn't need to be aware of each other (or their peers). The controller requests a service of the model, which simply publishes an event to all interested parties (controllers, views and potentially other models). Subscribers to these events can choose to handle them (by modifying some aspect of themselves and/or sending another request to the model). The model should always broadcast events at the safe end of any operation (i.e. not in the midst of an operation). /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
hmmm, in the MVC environment I work in (Ruby on Rails) the View does know of the Model. The Controller simply controls what Model instances get passed, not the shape or form of the Model.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
Hockey wrote:
- Controller notifies View
Not in my world. :) Controllers and views shouldn't need to be aware of each other (or their peers). The controller requests a service of the model, which simply publishes an event to all interested parties (controllers, views and potentially other models). Subscribers to these events can choose to handle them (by modifying some aspect of themselves and/or sending another request to the model). The model should always broadcast events at the safe end of any operation (i.e. not in the midst of an operation). /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
IMHO, wiring the whole model into the controler and then the controler into the view, is more like the Model-View-Presenter pattern; basically, what you're doing is proxying the model in order (usually) to change some attribute's representation to make it easier/simpler/more logical for the view to represent it. So the view and the controller are interdependent, and the controller depends on the model. the model is isolated, but the view and the controller aren't. In MVC, as I understand it, the controller is in charge of handling the state management issues attatched to the diferent environments, like web based apps and desktop apps, and maybe some particularities of the model, like the way it handles the view's requests: Event based vs. method based. Also, the controler should handle the type conversions in orther to pass parameters from the view into the model. In that case, the controller wires the events that trigger state change in the model, but the view directly pulls the attribute's values from the model. Anyway, I should say that I've been looking at those two patterns for a while, and still haven't made up my mind as to exactly what to call each one of the situations I described. Maybe you'll get more from Martin Fowler's article at http://www.martinfowler.com/eaaDev/uiArchs.html[^] than I did. If you ever manage to cleary state what is MVC and MVP, please make me know! i dissagree with your every single word, but I'll defend to death your right to say them. --Voltaire
-
I'm missing something... RoR is web-based like PHP...but RoR is a strict MVC implementation so I believe? Maybe it's my implementation...but how/why does your view need to be aware of the model? Why can't your controller instantiate the Model and View and pass the View the Model data? This way you keep the Model and View entirely independent (which is the primary goal behind MVC anwyays isn't it?).
I finally got a job doing something I enjoy and I"m good at...15 hour days seem like play time :P
Hockey wrote:
Why can't your controller instantiate the Model and View and pass the View the Model data? This way you keep the Model and View entirely independent
Surely the View has to have carnal knowledge of the Model? How does the View display data from a Model if it doesn't know there is a Title field or a Username field? If a Model has Field X and you want it displayed then the View must print out Field X. If you remove Field X from the Model then you need to remove it from the View. The View is very dependent on the Model. The Model does not have to be dependent on the View though. The Controller can be independent because it is just a conduit and doesn't have to have knowledge of the specifics of the Model or, to a lesser degree, the View. So as you say, the Controller instantiates a Model and passes it to a View.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
Am I wrong or does MVC have different dependencies when developing in an event based environment as opposed to a request/repsonse? While tinkering with MVC (PHP based) I have noticed that I can successfully keep dependencies out of the View and the Model having the controller manage both. Yet, I have read articles where it is suggested otherwise...my impression has been as follows: Event based development, like Windows applications: 1) User clicks button 2) Controller updates the Model 3) Model notifies the Controller of changed state 4) Controller notifies View 5) View pulls on Model I have read a few articles which "suggest" optional dependencies between each component of the triad...when really...I fail to see why the Controller can't simply handle dependencies - as it's basically the wiring that pulls the Model and View togather anyways. When building a web based applications...when would the view ever need knowledge of the model...the way I see it...the controller pulls on the model and passes that data to the view...or simply just pulls on the view or the model... Model and View have zero knowledge of each other...dependencies are centralized in the controller and I can't complain - despite my possibly doing something against traditional accepted MVC practices... Comments?
I finally got a job doing something I enjoy and I"m good at...15 hour days seem like play time :P
I'm trying to add a contribution to the discussion. Generally, the dependencies structure you presented allows for the model (and in some sens the view) to be completely independent from the information flow. In other words, if the application is statefull and it is also accessed by different points (i.e. different users, different kind of clients, different roles, ...), it is fundamental to have a back-notification system, handled by the controller but trigered by the model. PHP applications are normally stateless or "fairly statefull" (using sessions or filesystem) and generally they are accessed by only one way. In this case the flow is invoked by the HTTP REQUEST and normally both model modification and view notification are handled in the same REQUEST. That's why you are itched with unifying all messages into the controller. That's what I figure out. The question now is: which approach is the best for PHP / WEB based applications ? I think that no pattern has a universal implementation but it has still to deal with the environment / instruments used. MV
-
I think where we are differing is the environment were working under...the fact you made this statement:
Shog9 wrote:
I mean, the whole point of the view is to indicate the current state of the model in some fashion;
Suggests you are working in a event driven environment like Windows??? Remember, PHP primarily uses HTTP which is stateless, so I am not sure the same mechanisms apply in seperating MVC components... For instance, consider the following: 1) User clicks a HTML button - the browser acts as the client side controller (unless JS is used) 2) Server side script invoked - front controller dispatches to action controller 3) Action controller invoked - Does it return HTML or delete a file - or both? 4) Delete file - Model has been invoked 5) Return HTML to browser (Success or Failure) So you see, in this instance, why would the View need to know of the model as the action controller would simply need to Push/Pull on the Model and then the View? This way Model and View remain free of dependencies? I realize it works different in a Windowing environment, like MFC development, but thats exactly what I'm trying to figure out :P
I finally got a job doing something I enjoy and I"m good at...15 hour days seem like play time :P
Consider that MVC is an abstraction and is identically appropriate in both the web and the desktop ('event driven' world). In other words, events, or no events, is not an issue. Consider, also, that the web world is a variant of the event driven model of the typical windows application - and true non-event-driven models are (largely) a thing of the past (being any application without a universal 'dispatch' mechanism). IMO the 'gap' between the browser and web server should be considered an aspect of some pattern other than MVC. This is difficult (and I'm only formulating my thoughts as I type) because the controller of MVC is 'all about' managing the interaction, and the question "if it's not the one managing how the browser and the server-side code interact, what is it there for?" arises. For me, the controller in MVC is about the abstract flow of control: If I click this button the controller knows which model I'm currently working with and how to inform the model that a specific action has been requested. The view, as we know, then needs to get from the model the revised data it needs to display. MVC on the web works best, for me, if ALL of this behavior is server side; that means that the view part of MVC is on the server: I am distinctly NOT making any kind of correlation between the browser and the MVC View. In fact, the gap between the browser and server is an internal detail of the view (and also an internal detail of the controller). In other words, inside the View and the Controller there is, effectively, an implementation of the Proxy pattern. HTH Chris Use what talents you possess; The woods would be very silent if no birds sang there except those that sang best. (William Blake)
-
Am I wrong or does MVC have different dependencies when developing in an event based environment as opposed to a request/repsonse? While tinkering with MVC (PHP based) I have noticed that I can successfully keep dependencies out of the View and the Model having the controller manage both. Yet, I have read articles where it is suggested otherwise...my impression has been as follows: Event based development, like Windows applications: 1) User clicks button 2) Controller updates the Model 3) Model notifies the Controller of changed state 4) Controller notifies View 5) View pulls on Model I have read a few articles which "suggest" optional dependencies between each component of the triad...when really...I fail to see why the Controller can't simply handle dependencies - as it's basically the wiring that pulls the Model and View togather anyways. When building a web based applications...when would the view ever need knowledge of the model...the way I see it...the controller pulls on the model and passes that data to the view...or simply just pulls on the view or the model... Model and View have zero knowledge of each other...dependencies are centralized in the controller and I can't complain - despite my possibly doing something against traditional accepted MVC practices... Comments?
I finally got a job doing something I enjoy and I"m good at...15 hour days seem like play time :P
Isn't it wonderful how patterns simply coding :)
Rocky <>< Latest Code Blog Post: New enhancements to VS WYSIWYG! Latest Tech Blog Post: Scratch: fun for all ages for free!
-
Consider that MVC is an abstraction and is identically appropriate in both the web and the desktop ('event driven' world). In other words, events, or no events, is not an issue. Consider, also, that the web world is a variant of the event driven model of the typical windows application - and true non-event-driven models are (largely) a thing of the past (being any application without a universal 'dispatch' mechanism). IMO the 'gap' between the browser and web server should be considered an aspect of some pattern other than MVC. This is difficult (and I'm only formulating my thoughts as I type) because the controller of MVC is 'all about' managing the interaction, and the question "if it's not the one managing how the browser and the server-side code interact, what is it there for?" arises. For me, the controller in MVC is about the abstract flow of control: If I click this button the controller knows which model I'm currently working with and how to inform the model that a specific action has been requested. The view, as we know, then needs to get from the model the revised data it needs to display. MVC on the web works best, for me, if ALL of this behavior is server side; that means that the view part of MVC is on the server: I am distinctly NOT making any kind of correlation between the browser and the MVC View. In fact, the gap between the browser and server is an internal detail of the view (and also an internal detail of the controller). In other words, inside the View and the Controller there is, effectively, an implementation of the Proxy pattern. HTH Chris Use what talents you possess; The woods would be very silent if no birds sang there except those that sang best. (William Blake)
I think the main point is what MVC is trying to achieve, and it had better be a real world problem or it isn't worth achieving it. I think the real world problem is that, prior to using MVC separation of concerns, changes in the user interface used to require changing the model and the controller. By using MVC you break the dependency that MC have on V, but it doesn't matter if V has a dependency on MC because it really only exists to render aspects of MC. For example, we have successfully experimented with swapping a windows front end with a web front end. Both the windows and web front ends (V) depended on the M and the C (which made them easy to code) but the M and the C were able to remain unchanged in both instances. So basically MC is the bit you want to keep stable and V can change (as they often do). Separating M and C also achieves other 'real world' goals of allowing elements of the solution to vary independantly of each other. Any separation of concerns adds complexity and should only be done for a real reason. Hope that helps Andrew