I have a object that is responsible for controlling screen navigation. A presenter can call one of two methods on this navigator object NavigateTo(string screenName) and NavigateTo(string screenName, object data). This latter method allows some context data to be passed to the navigator object.
Would it be the wrong approach when calling the NavigateTo(string screenName, object data) to pass the calling presenter as the data to the navigator and then allow the navigator object to use this to extract data from the view and/or model.
Some advice on this matter would be greatly appreciated.
Passing the Presenter to NavigateTo is a good choice. If you have multiple presenters you may want to write a interface that NavigateTo can use and have each presenter implement that interface. But if you just using one presenter for this or they already share some common interface then this is not needed.
One idea behind MVP is that you are change the view without effecting the underlying UI Logic. Passing the presenter doesn't effect this goal of MVP as you can change the view the Presenter is using. Now if you are allowing direct access to the raw view through the presenter (by exposing a view property) then that not good. What you want are methods on the presenter to expose the needed information to NavigateTo. That way when you chance the view you re implement the code behind those methods.
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 have seen numerous questions on MVP that mostly revolve around the View and Presenter.
My question is more about the interaction of the Presenter with the Data Access Layer.
In my application, my Model very closely reflects the View. i.e. My model only contains the information needed to be displayed on the UI. Hence its really a "ViewModel".
I have the following questions:
Should the Presenter be responsible for making a call into the Data layer?
Should the Presenter map the returned Data to the ViewModel?
Should this mapping take place inside the Presenter? In a separate class?
Is there a pattern I could take advantage of?
Or am I completely off track?
According to my understanding of mvp the presenter does all of the leg work while the view simply arranges the data. Because of this I generally find little need for a ViewModel since the presenter is controlling the data binding directly.
As far as data access goes, I find it a lot cleaner to have a Helper object that handles the DAL.
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 have a pretty good idea how each of these patterns work and know about some of the minor differences between them, but are they really all that different from each other?
It seems to me that the Presenter, Presentation Model, ViewModel and Controller are essentially the same concept.
Why couldn't I classify all of these concepts as controllers? I feel like it might simplify the entire idea a great deal.
Can anyone give a clear description of their differences?
I want to clarify that I do understand how the patterns work, and have implemented most of them in one technology or another. What I am really looking for is someone's experience with one of these patterns, and why they would not consider their ViewModel a Controller for instance.
I'll give some reputation points for this, but I'm looking for a really good answer.
Besides the already mentioned great reads (Fowler & Miller) and to reply to your point on differences among controller/ presenter/ ... from the developer's point of view:
Controller in MVC:
Controller is the actual component that gets called as a result of user interaction. Developer does not have to write code to delegate calls to the Controller.
Controller gets current values somehow from the View/ context/ bag/ whatever, but you would not really say that it interacts with the View.
Controller decides in the end which View to show back to the user. In that, Controller shows an explicit notion of application navigation workflow too.
Presenter in MVP:
Presenter has methods called by the View, which is the actual component receiving control upon user interaction. Developer has to write some code in the View in order to call the Presenter.
Presenter gets current values somehow from the View or receives them from the View upon call. Presenter calls methods on the View in order to set its state (populate it says Josh Smith). A View method called by the Presenter might have several small settings performed in its body.
Presenter does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.
PresentationModel in PM:
PresentationModel has methods called by the View, which is the actual component receiving control upon user interaction. Developer has to write some code in the View in order to call the PresentationModel.
PresentationModel has a much more chatty communication with View compared to a Presenter. It also contains more logic in order to figure out the value of all the settings to apply in the View, and to actually set those in the View. Those View methods in turns have almost no logic.
PresentationModel does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.
ViewModel in MVVM:
ViewModel has methods called (& properties set) by the View, which is the actual component receiving control upon user interaction. Developer has to write some (declarative) code in the View in order to call the ViewModel.
ViewModel has not an explicitly chatty communication with View compared to PresentationModel (i.e. it does not call View a lot, the framework does it). But it has a lot of properties that map 1 to 1 with View settings. It still contains the same logic to figure out the value of all those settings.
ViewModel does not explicitly show a notion of application workflow. It is usually thought of as returning control to the calling View.
Copying somehow what Josh Smith says (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx): MVVM pattern is a special case of PM that takes advantage of a framework (like WPF/SL) in order to write less code.
Martin Fowler has a page on UI design patterns, in which he defines and then talks about MVC, MVP and other patterns.
http://martinfowler.com/eaaDev/uiArchs.html
A Controller is active in controlling the UI. For example it would handle any events triggered by the UI and deal with them appropriately.
A Presenter on the other hand is more passive, and simply displays data through the UI, which handles it's own events etc, or delegates them through the presenter to a service or command.
A ViewModel is a specific example of a Presenter, designed for use with WPF/Silverlight binding.
A Presentation Model is a model that can be presented directly by the view, so for example if your models implement INotifyPropertyChanged for data binding, they would be Presentation Models.
The difference between them is essentially in how much code is in the view. The choice between them is in fact a choice of technology for application such as WFP, WinForms, ASP MVC(2). The basic idea of separating logic from presentation is the same.
Here is very good article about all three.
EDIT:
One more article - comparison.
In my opinion, there are no real conceptual differences between MVP, MVVC, MVC and Presentation Model. There are some detailed differences, but in the end, it can all continue to be thought of as a Model View Controller setup. The extra naming just serves to create confusion, and I think it would be better to adopt terminology that allows for a certain amount of latitude in describing a controller.
At least in .Net, MVP is used as a design pattern. This usually is used with Windows Forms applications, or classic ASP.Net . With MVC, and MVVC, these are usually used with ASP MVC, which uses a fairly different architecture than normal ASP.Net.
One important distinction between MVP and MVVM is that VM can be used with many views, MVP is usually 1-1 between Presenter and View with a contract interface that enforces its methods.
Android has done much to incorporate MVVM with the ViewModel component that is built on top of a retained Fragment. It is the pattern of choice for Architecture and well suited for any app.
Using the MVC pattern in a desktop application, what's a good approach to introducing a view to its respective controller, and vice-versa? E.g., should you use constructor injection to give the view its controller, then have the view call a setView method on the controller and pass itself as the argument?
(Question isn't specific to any framework/platform.)
Views should be as dumb as possible. They shouldn't know about, or rely on having specific controllers instantiate them. At best they should have access to some kind of base controller class reference that is handed to them upon construction, usually as part of the "view data" object which wraps the Model to be used as well.
Your controller should be responsible for instantiating the view, giving the view the model it will be displaying, and returning the view's result. The view shouldn't be calling back into the controller to tell it what to return, as this gives control of the logical flow to the View, which isn't really MVC-like.