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).
Related
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...
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.
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.
Can someone explain the relations between elements of MVC (with the active model), painted on this picture?
I see it like this:
Controller → Model — a model's data changing by the controller.
Model → View — the model notifies the view about changing.
View → Model — the view get data from the model.
View → Controller — the view notifies the controller about user's actions (for example, button pressing).
Controller → View — but this relation, as I think, is unnecessary and contradict MVC rule about developing the controller independent from the view: it should interacts through the model.
The MVC is rather broad subject, there are many variants of this pattern, and many implementations. I have seen solutions in which one of the responsibilities of a controller was to create an instance of a View with associated Model attached. This might be the relation you're looking for.
One other thing - existence of controllers independent from the view is a myth in real-life scenarios, in my opinion. Sooner or later you need to provide a functionality which explicitly tightens the View - Controller relation and is unusable (or simply different) without that particular View. Besides it is far more efficient to embrace the fact that different types of views behave differently and turn this into advantage by building tailored Controllers instead of pretending that we could deal with every aspect of user interaction with just one.
I think the relation between the between the model and view is wrong (at least the solid one). The way I see it in an MVC pattern is that everything goes via the controller. So in the view, the user selects the data he wants to see.This request is send to the controller. The controller is going to get the data in the model and the model gives back the requested data. The controller then sends it back to the view and the view outputs it to the user.
As for the controller->view relationship you have highlighted
The controller needs to be able to choose the appropriate view that is displayed
AFAIK, that is the only relationship the controller has with the view (aside for the view routing messages to the controller). MVC is a little different from MVVM/MVP because you don't necessarily have just one view for each controller. For example, you could have a user controller and you might have a view for displaying information, one for editing users, and one for adding users. With the other two methods, there is a one to one relationship between views and ViewModels or Presenters.
Controllers being independent of the view is not a myth
Maybe I haven't used MVC enough in other scenarios but I have always kept the controller independent of the view. In fact if you have any view code in your controller (ie function with ListBoxEventArgs, referring to view components, etc) then you have not achieved the goal of this pattern which is to separate your view from your logic and model. I believe ASP.NET MVC makes views completely independent of the controller by having some class that manage tracking the initiated views. This class is available to all the controllers (through inheritance but dependency injection is fine too) and then each controller just picks a view to display using this class. The view can be selected with a constant or a string (in fact, I believe it is even possible to select them with no argument and based on the method name).
view->controller relationship
With ASP.NET MVC, view's are independent of the controller too since events are routed to the controller via url. However. in other non-web situations, it is fine to just forward your events to the controller by directly calling controller methods in the code behind.
Implementation details
On my blog, I wrote an article that covers the implementation of MVC a bit and should help answer your questions.
MVVM vs MVP vs MVC: The differences explained
Personally, I think the type of MVC shown in your diagram is not being employed as often today as in the past and it might be hard to find examples that use those relationships as shown. The reason is that if the view is able to talk to the model, then I think developers will opt for MVP or MVVM (and use a view model) over MVC. The only case I can think of where the view is not able to continuously talk to the model is in server client situations. In this case, there are many popular MVC frameworks like ASP.NET MVC is still popular today.