OOP
in [OOP]
|
Prev: ooad suggestion
Next: Call for Papers: International Conference on Computer Science and Applications ICCSA 2008
From: Taras_96 on 23 Apr 2008 23:07 I have a few questions regarding the MVC pattern. The View ======== The view provides the user 1. A way in which to interact with the model by generating events 2. A way in which to view the model However, it does not directly manipulate the model. Any interractions with the model are passed onto the respective controller so that the controller can take the appropriate actions. So for example, where the view displays some text in a text box: 1. User hits keyboard - generates event 2. Controller handles event by updating text in model 3. Model informs view that state has changed. View updates text - Would the view update the entire state, or can it know somehow exactly what has changed? - Java Swing is not MVC, as the text box stores it's own state Is this correct? The controller ============== Controller - Handles all events from the view - Each view has one controller (a single controller may be composed of 'sub-controllers', eg: a sub-controller per event) (like at http://www.theserverside.com/tt/articles/article.tss?l=JavaGUIDev which shows there are models for each subcomponent, which are all part of a larger domain model). Is this correct? The View/Controller relationship ================================ http://java.sun.com/blueprints/patterns/MVC-detailed.html shows that the controller communicates with the view, and is labelled in the diagram as 'view selection'. If I understand the pattern correctly the controller should never be asking the view for anything to do with the state. For example, if a key was pressed in a text field, the controller won't query the text field to see what is currently entered (this is done in Swing), as the label shouldn't be updating it's own state (instead this information would be passed to the controller in the generated event, eg: keyPressedEvent.GetKeyPressed() would return 'a'). So does this interraction represent those events that require the view to change, but not the state (eg: resizing the window, scrollbars, etc.)? I suppose then the view would store it's own state, which is not part of the model. 'Design Patterns' (gamma et al) states: "The View-Controller relationship is an example of the Strategy (315) design pattern. A Strategy is an object that represents an algorithm. It's useful when you want to replace the algorithm either statically or dynamically, when you have a lot of variants of the algorithm, or when the algorithm has complex data structures that you want to encapsulate." So in MVC is the AlgorithmInterface() of the Strategy Interface (as on page 315 of design patterns, gamma et al) the interface which contains the event handlers, ie: Button1Pressed(), Button2Pressed(), etc.. methods? The Model/Controller ==================== http://www.javadude.com/articles/vaddmvc1/mvc1.htm shows that the model communicating with the controller ('I have changed'). AFAIK, this is not MVC - the model never communicates with the controller (only the other way around). Thanks Taras
From: Phlip on 24 Apr 2008 09:18 Taras_96 wrote: > The view provides the user > 1. A way in which to interact with the model by generating events > 2. A way in which to view the model > However, it does not directly manipulate the model. Why not? > 3. Model informs view that state has changed. View updates text > - Would the view update the entire state, or can it know somehow > exactly what has changed? Yes. Refreshing a whole form is pernicious. And because most controls store their current state, it should just remain where the user left it. If some fields must update dynamically, they should use the Observer Pattern to receive updates from the Model. This is only for updates that the user _shouldn't_ enter. > - Java Swing is not MVC, as the text box stores it's own state All GUI controls store their controlled variable's state. That's orthogonal to MVC, > Controller > - Handles all events from the view > - Each view has one controller No, because you just contradicted yourself: > (a single controller may be composed > of 'sub-controllers', eg: a sub-controller per event) One big issue with Rails's implementation of MVC is each View gets only one Controller. This is in blithering indifference to Rails's capacity to assemble Views from Partials - snips of RHTML template that can bond together into a complete page. If you need a partial to call an Action in a Controller (to handle an input event), and if you share that partial between two Views, you must put the Action in ApplicationController, which is the root class of all Controllers. Everybody gets the Action. This directly contradicts the design guideline "no God Classes". So you should instead build an app from a pool of controllers, model objects, and views, and mix-and-match them however you like. > If I understand the pattern correctly the controller should never be > asking the view for anything to do with the state. For example, if a > key was pressed in a text field, the controller won't query the text > field to see what is currently entered (this is done in Swing), as the > label shouldn't be updating it's own state (instead this information > would be passed to the controller in the generated event, eg: > keyPressedEvent.GetKeyPressed() would return 'a'). So does this > interraction represent those events that require the view to change, > but not the state (eg: resizing the window, scrollbars, etc.)? I > suppose then the view would store it's own state, which is not part of > the model. That's perfectly acceptable! The statement "the Controller should not query the View for state" simply means the Controller should not treat the view like a database and pull entire records from it. When in doubt, read them from the Model! It's the persistent part. > The Model/Controller > ==================== > http://www.javadude.com/articles/vaddmvc1/mvc1.htm shows that the > model communicating with the controller ('I have changed'). AFAIK, > this is not MVC - the model never communicates with the controller > (only the other way around). The best way to understand this is under unit testing. Anything a user can do to a Controller, thru a View, a unit test can do the same way. Anything thing the user can do to the Model, thru the View and Controller, a unit test can do, the same way... --> without help from the View or Controller <-- So if the GUI has a field saying "record name", and a button called "save", this means a unit test on the Controller can call its setName() method, and its saveRecord() method. Both should work without help from a View. Next, a unit test on the Model can say aRecord.name = "some name", and can say aRecord.save(), all without help from a View or Controller. Declaring who can ask whom for what is just a system of guidelines for decoupling things. The awesome goal of MVC, which I have experienced more than once (even in Rails!) is you can add a feature to your code without tangling your existing code up with excessive 'if' statements to handle all the conditionals of business logic. These complexities all get partition into the correct junctures, within the pattern. -- Phlip http://c2.com/cgi/wiki?AssertYinYang
From: Taras_96 on 24 Apr 2008 22:21
Hey Phlip, I didn't fully understand your reply: On Apr 24, 10:18 pm, Phlip <phlip2...(a)gmail.com> wrote: > Taras_96 wrote: > > The view provides the user > > 1. A way in which to interact with the model by generating events > > 2. A way in which to view the model > > However, it does not directly manipulate the model. > > Why not? > Wouldn't this unnecessarily couple the view and the model? Plus it isn't the view's responsibility to update the model - the responsibilities of the view and the controller should be clearly defined, and having some model manipulation code in the controller and some in the view would result in the loss of a clear partitioning of responsibilities between objects, making the code less clear (IMO). > > 3. Model informs view that state has changed. View updates text > > - Would the view update the entire state, or can it know somehow > > exactly what has changed? > > Yes. > > Refreshing a whole form is pernicious. And because most controls store their > current state, it should just remain where the user left it. > > If some fields must update dynamically, they should use the Observer Pattern to > receive updates from the Model. This is only for updates that the user > _shouldn't_ enter. > I think I'm getting a bit confused between the state stored in the model, and the state of the control. If you enter 'foo' into a text field, then the state of the text field is changed to reflect this, but which doesn't immediately effect the state of the model. The controller would handle the event, update the model, which would then inform the views of the state change. The original control may update it's own state to reflect the state of the model. Is this correct? In any case, the view with which the user interacted would get notified of the state change, as it would be on the subscription list, so I don't see how you can differentiate between updates that the user enters and updates the user doesn't enter, as there may be controls on a view which are sometimes updated by the user, and sometimes updated some other way. If a user interacts with a text field, I see the interaction going something like this: 1. Text field on view1 changed. New text stored in text field control. 2. View1 notifies controller of event 3. Controller updates model 4. Model notifies all subscribers of the state change 5. As view1 is on the subscription list, it is notified. It either a) realises that the state change was made by itself and takes no action, or b) takes action regardless of whether it triggered the state change (the action would have no net effect, as view1 already reflects the current state of the model) - option b) seems cleaner IMO. >> - Java Swing is not MVC, as the text box stores it's own state > > All GUI controls store their controlled variable's state. That's orthogonal to MVC, Could you explain this a bit further? Are you saying that all GUI controls (not talking about a specific implementation here) store their own state, and this is something different to MVC? What 'controlled variable' are you referring to? > > > Controller > > - Handles all events from the view > > - Each view has one controller > > No, because you just contradicted yourself: How? Thanks Phlip. |