Following this article There are two schools of thought with regard to whether the View interacts directly with the Model or not.
I'm interested in the case where View don't interact with Model. If only Controller knows about View but not View knows about Controller we can easily update View with Model data (write some text, for ex.) by calling View and Model methods in Controller.
But how could Controller and Model react to View changes (button push, for ex.) if View don't know about Controller or Model?
-One solution-
One way to make 2 objects communicate with loose coupling (in your case views don't know about controller and vice-versa) it to use a "messenger" pattern.
The 'messenger' is an object known by all the others. Using the 'messenger' object:
You register objects (your views) to send messages
You register objects (controlers, models...) to listen to specific messages
In this way, a model can react to a specific view's event because it is registered into the messenger.
There is a full example here (C# code):
Light messenger pattern
Tell me if it s what you were looking for...
Related
The user-input is received by the Controller. The Controller manipulates/edits the Model.
The View can query the Model in order to obtain the new state for diplaying. The point I do not get is who actually notifies the View of changes? Because in the schematic overview, It seems that the Controller sends modification messages and that the Model also notifies the View of changes.
Even in the example, both notify the View. If the controller sends for example the position of the needle, why must the Model still notify the View?
[The figures are from the slides of our prof, so they are correct anyway]
It was becoming a bit confusing, so I googled to see what some leading authorities have to say, because Wikipedia and the first hits are not as good as they seemed to be.
Model. The Model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the View), and responds to instructions to change state (usually from the Controller).
View. The View manages the display of information.
Controller. The Controller interprets the mouse and keyboard inputs from the user, informing the Model and/or the View to change as appropriate.
So it seems that the Controller notifies the View.
But it is important to note that both the View and the Controller depend on the Model. However, the Model depends on neither the View nor the Controller. This is one of the key benefits of the separation. This separation allows the model to be built and tested independent of the visual presentation.
And of course the Controller cannot be the only one who changes the Model. For that reason there are indeed some variations:
The passive model is employed when one Controller manipulates the Model exclusively. The controller modifies the Model and then informs the View that the Model has changed and should be refreshed. The Model in this scenario is completely independent of the View and the Controller, which means that there is no means for the Model to report changes in its state.
The active model is used when the Model changes state without the controller's involvement. This can happen when other sources are changing the data and the changes must be reflected in the Views. Because only the Model detects changes to its internal state when they occur, the Model must notify the views to refresh the display.
-> Explains the case.
Model does not have to necessarily notify the View - in that case you get a passive implementation of MVC, see wikipedia.
The model can for example compute something in the background, e.g. it could be computing positions of particles in a particle system and here and there it could notify the view to update itself - i.e. the push model which is often more efficient than polling the model from the View.
For example before WebSockets and Comet, it would be always the Web view notifying the Controller which would poll a Model and render a new View. With WebSockets or Comet you can have the Controller notifying the View.
In any case, there are myriads of spins on implementing MVC, it's not set in stone and of course you can adapt it to your use case.
In a GUI application, I am using an MVC with a Passive View, as described here.
This pattern is yet another variation on model-view-controller and model-view-presenter. As with these the UI is split between a view that handles display and a controller that responds to user gestures. The significant change with Passive View is that the view is made completely passive and is no longer responsible for updating itself from the model. As a result all of the view logic is in the controller. As a result, there is no dependencies in either direction between the view and the model.
So far, my Controller registers as a listener to existing, static components created by the Passive View itself at initialization. Now, the Controller needs to dynamically create a variable amount of UI components, depending on the Model (concretely, right now I am talking of a grid of checkboxes - the grid's dimensions is variable).
Here is where my hesitation lies:
Should this dynamic UI creation code be implemented in the Controller? This would lead to less complex code resulting from keeping the View unaware of the Model, but a part of the presentation would be decided by the Controller...
Should the View propose a generic, Model-independent way to create the UI components on demand, let the Controller use it and register listeners to the retrieved UI components? Here the Controller would have to convert back and forth between Model objects and generic objects (concretely, strings, integers, ...).
Whenever a view needs dynamic control creation, it tends to be for a collection of something. This means your Presenter/Controller does not need to create all of the logic, but call a method on the view which will create the controls.
On the View:
void PopulateUserOptions(IEnumerable<String> options)
{
foreach (var item in options)
{
\\create and add your controls to the form
}
}
This way the controller is expressing when a controll should be created etc, but leaving it to the view to decide how to do it.
I was going through the articles describing the MVC pattern. None of them were clear on explaining the role of Controller in MVC. Some says Controller can make changes to the view such as disabling a button or changing the text color whereas some says any changes to the view should be done inside view only. Can you please give me tips on the following question?
1) Can any change pertaining to the view be done inside the controller?
2) What not should be written inside a controller?
3) It is right to say "View should do all the changes by itself when a new recordset is generated by the model, as the view queries model directly, and controller is not involved in this transaction?"
4) I have heard this statement about MVC "In current version of windows application development. View is capable to handle the event(like button press) and the controller is called when needed.It is stupid to delegate the event listening to the controller now." Doesn't this sound more like a MVP?
Thanks. Hoping to get some help here.
In my opinion:
1) The controller changes the data provided to the view, so in a way, yes. The view should just manage the presentation of the data provided to it by the controller.
2) The controller should contain all code to handle any actions taken by the user. Depending on the size of your application, the controller can hand the action off to a business layer to do the work then gather view data once the business layer is complete and hand it back to the view. Or, if you don't have a business layer, it can do the work directly.
3) In true MVC, the view should not have access to the model directly. The controller should create view objects from the model and pass them to the view. In any case, the view should never do any real work other than presentation.
4) I don't know MVP so cannot answer this question.
1) Controller responsibility is primarily "execute an action, choose an appropriate view, provide some data to that view and return the view to a user".
2) As MVC tries to separate presentation logic and UI rendering, I believe, controller shouldn't attempt to perform any of view responsibilities: listening to UI events or pre-formatting of values dateString = data.ToString('YYYY-MM') - that's all should go to view.
3) in MVC view knows all about a model - model is rendered by view without any controller involvement (that's primary 'issue' fixed by MVP, where view should and model should unbound as much as possible). However it's not recommended for view to query model directly. Instead, all data changes should be reported to view by model using Observer pattern.
Consider the following -
schema from wikipedia article - dashed line from model to view indicates that fact. Just keep in mind that model is more viewmodel here and shouldn't really be a part of BL layer.
So here scenario could be the following:
User clicks "add item"
View sends request to the controller with the item data
Controller makes call to BL, which makes changes to the model (adds new item to the list).
Model fires "updated" event to the view (or "error" event, if there are some issues in underlying layers)
View updates UI according to changes reported.
4) The statement is perfectly true. In MVC you shouldn't do that. I assume, in MVP you shouldn't do that as well - I mean, listening to events from UI directly. That should be done either by forwarding event by view; or using a platform-independent view representation, like
inderface IMyGridView
{
event ItemEvent AddItemClick;
}
(which doesn't make sense for MVC, as view is pretty much independent from a controller and mostly all view actions are result in calls to controller).
in the tutorials from http://www.vainolo.com/tutorials/ the position of the model is saved in the model. I want to save all data to file and want to get the same view, when I load the file.
Searching for an answer for this question, I got another more important question:
Is the GEF really a MVC framework?
GEF Controllers tells the mvc controller role is taken from the EditPart. It creates the specified objects.
Regarding the examples the controller holds view parts, but the mvc pattern tells, that the controller only reacts on user interaction and tells the view, it has to update or what ever.
Concluding on it the following code is wrong, because it is part of EditPart and it changes:
public void refreshVisuals(){
IPersonFigure figure = (IPersonFigure)getFigure();
Person model = (Person)getModel();
figure.setName(model.getName());
figure.setSurname(model.getSurname());
}
Regarding wikipedia the view has an observer on the model, so the following sentence from GEF is wrong, isn't it?
The EditPart syncs the actual model state to the view and implements the observer.
In the MVC pattern, the controllers must listen to the changes of the model. In GEF, EditParts are the controllers so they must listen to their model to update the view according to the new state of the model.
So what is correct?
To prevent cross-posting have a look on http://www.eclipse.org/forums/index.php/m/755178/.
The wikipedia states a the start of the article on MVC that " MVC comes in different flavors (MVC overview). Sometimes the view can read the model directly and update itself, sometimes this is done by the controller.
The primary concept that MVC provides is decoupling the presentation from the view, which should contain no logic. Changes to the model are executed by the controllers, and changes to the view are caused when the model is changed. But this does not mean that the controller can't be the one who updates the view when the model changes. Someone has to do it, right? I personally think that having the view directly read from the model is not a good practice since it makes them too dependent, and that model and view should be completely separated. This is great when you have to make changes in your model (for example a field is changed from being real to being calculated) - you don't have to change your view (but you may have to change your controller, but this is normally easier).
Hope this clears things up for you.
Being a relative newcomer to MVC I'm musing over a little problem. I'm developing a page which relies on a collection of my viewmodel objects. All good. But, as the page has relatively complex functionality I need to get at other objects or collections of the main domain model to display in the UI. Admitedly rather more light weight objects. What's the best way to achieve this?
What I do is create a custom class to encapsulate ANY data I need to display in any certain view / action. So for my Admin areas User controller, I have a AdminUserIndexViewModel class that holds my list of user business objects. I also put any other data I need to display into this class.
For my AdminUserEditViewModel (that corresponds to my Admin Area, User Controller, Edit Action) I might have a single User class, which itself has its Roles attached to modify if need be. If you need to put other information like user settings, or preferences, etc...
If they are not part of the viewmodel you are currently working with then you can use Html.Action to call into another controller method to render another inline view through a controllers method.