Should models be shared between controllers, so that two controllers have the same model, or should they listen to an global eventbus to get notice when the model is changed?
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...
I've been learning how to build web applications with Laravel and Vue.js and I understand the part where the user uses the view in order to send requests to the controller which then manipulates the model. I absolutely see that flow in my applications.
What I am not so sure about is why in MVC diagrams like this one: MVC pattern diagram from Wikipedia. The model directly updates the view but in my applications it seems that the Controller is the one that gets the changes from the model and sends that to the view (via HTTP).
Is there something that I don't quite understand?
In this diagram view is a representation of model. when model changes view changes to represent the model. in a real MVC application controller may send model to view (this model is called view-model which is a special type of model and it may get populated dynamically by controller using back end model). Some MVC applications have two types of models a model (which may be a database for back end) and a model (called view-model which is for representation and will be send to view). For example ASP.NET MVC has this type of view-model.
What is ViewModel in MVC?
https://en.wikipedia.org/wiki/Model–view–viewmodel
If I am using multiple viewControllers, do I need to create a separate UIViewContoller class for each one of them or can I associate this same new class with each individual viewController? Under what circumstances would I create a new class to associate with a separate VC?
thanks.
View controllers manage the logic of your view, providing a way to channel the data between the view and the mode, and react to events initiated by end-users through the user interface.
If multiple views happen to share the same logic of model-view interaction, it is a good idea to share view controllers among them. However, this is somewhat rare: in practice, different views call for different view controllers. So in practice you create a new class for a new view controller almost every time that you need a view controller. You can also start with several view controllers, and then unify some of them if you spot sufficient number of commonality in their code.
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.
I'm a little bit confused about these two programming patters: MVC and MVP.
Which are the main differences between them?; I have been searching on the net and I made a couple of examples of both of them, but I'm even more confused, because in some sample web pages MVP uses more than 2 interfaces to communicate the presenter with the view layer (some ones even have completely blank interfaces, only declarated), but in other ones it only takes two interfaces to transport data from presenter to view. Which is the correct way of applying that pattern?
On the other hand, I have been working on MVC for a while, but until now, I realize that maybe I had been aplying the pattern in the wrong way. I have had this:
Model: C# classes that behaves like the bussiness objects.
Controller: C# classes that uses the model objects to fill them or manipulate them.
View: C# aspx pages to show the model objects; the controller is the responsible of sending the model objects to this layer after manipulating and/or filling them with data.
I hope you can clear my doubts. Thanks in advance.
MVC
View is responsible for rendering the UI elements. The controller responds to the UI actions. And the model handles the business behavior. The controller is responsible for which view want to display. The whole business logic layer can be represented by the Model. The view and the model are tightly coupled.
MVP
View is responsible for rendering the UI elements. The role of controller is replaced with a presenter. The presenter mediates the actions between both models and views. There isnt a mechanism for binding views to view models. So we rely on each view implementing an interface with the view