I have seen some basic samples on WinForms regarding the MVP Pattern.
If I have 5 controls on my winform than i have ONE presenter that takes logic from those 5 controls to forward of the logic to Model or something to that effect.
I have a main shell and on that shell I use Tab Pages in the main content area.
All the Tab Pages and controls that reside on those tabpages are created at runtime.
how many Presenters do I have?
One Presenter
as many Presenters as tabpages?
as many Presenters as controls on individual tabpages?
as many Presenters as total controls?
"How many presenters?"
See MVP - How many presenters
Related
I have a C# project in WPF. I've worked with MVC before and I am now trying to get around with MVVM in combination with XAML.
I have multiple models, I have one GUI Window with Tabitems, and I have multiple ViewModels.
Each tab item is related to each model, therefore I have a ViewModel for each model.
Now I want to use binding (why else use WPF/XAML). How do I bind a button to a command in ViewModel X?
E.g.:
Two Models: house and person
View: Two TabItems in the GUI, one TabItem about all interaction with houses, and one TabItem for persons.
Two ViewModels, correlating with each TabItem.
I have a command to put a house for sale.
I see alot of code that just binding to the name of the command, but since I have multiple views, and not just 1, how do I do it? Should I create 1 ViewModel that will handle all other ViewModels?
I see alot of code that just binding to the name of the command, but since I have multiple views, and not just 1, how do I do it?
Make sure you understand how the binding system works. You're binding to a DataContext. So, if each individual tab has a separate DataContext value set, then you can bind using the name of the command.
Knowing this, you can proceed using the pattern you've established. In my humble opinion, I think it will get much too complicated. Majority of MVVM developers are applying a one-to-one relationship with the View to ViewModel (things get tricky when talking about UserControl objects though). Nothing is set in stone though, so ultimately it's up to you on how you want to proceed.
I guess you have limited number of viewmodels. So you have 2 choises: first, is to use DataTemplateSelector, and the second is to define in xaml each TabItem view and Bind each Content to necessary VM.
Background
I'm working on a silverlight page that has grown quite complex. Its 650 lines, contains It has four grid views, a tab control, etc. Also note we're following the MVVM pattern. This is silverlight 5, if that matters.
The page seems suitable to be split into a main page with four controls. I doubt the controls would ever be reused in other pages.
One benefit is that with all of the indenting, it is a bit awkward to work with the xaml. Second benefit is my belief that it would be easier to follow/understand if the controls were split apart.
Questions
If I split the xaml into seperate controls, should I also split up the ViewModel? For the same reasons, it would make the view model less complex and easier to understand in the context of just the control it works with.
Are there any potential problems with splitting the controls? Perhaps binding issue if for some reason a checkbox on one control should affect the behavior of a different control? But this might be solved by having the various view models have a reference to each other?
I would say that yes you should split the page up into seperate controls and yes you should split up the viewmodel if the cost of doing so will be less than the cost of the maintenance difficulty created by the current model.
Most of the challenges that this presents can be addressed by having a main viewmodel that contains references to all of the child viewmodels and manages the relationships between them.
I have a question on implementing the MVP pattern in a Windows.Forms application.
I have a user control which is used from 2 different forms.
Basically, where shall the presenter be declared (and shall I have 2 different presenters for each form, not a single one for the user control, it be able to distinguish itself what kind of behaviour to take, depending on the form using it) - in the code behind of the user control or of the form using it ? The behaviour (logic on save and filling the fields of the user control) is quite different.
Thank You!
One presentation can have multiple views. e.g. A list of dirs and files in a treeview or in a listview or anything else.
So One Presenter can satisfy the needs of multiple Views.
A View can have extra logic around how to present(convert to relative UI) the information provided by Presenter.
Each View can privately instantiate Presenter. Also because both the view are different UI representation of same presentation, they can should be extracted into a common interface (IXXXView) which can be than be passed into the Presenter.
imo, Passive Views are very strict about converting the data into primitive datatypes which can than be hooked to UI, using a Supervising View would give greater flexibility.
I am just trying to wrap my head around MEF.
And as I am really going to love it ( I guess ) I started my first sample project and immediatly stumbled into a big problem and now I am asking myself if I can use MEF for my scenario at all and that is the following:
Imagine that one got some kind of dashboard with, let's say, five regions and above each region there are two comboboxes. The values in the first combobox represent different possible views (for example, chartControl, tableControl, pictureControl, ...) and the values of the second combobox represents the different data sources for the currently selected control.
As the controls are very big in size one wants to download them as needed.
If the user selects one comboboxitem the corresponding control xap should be loaded and displayed in this specific region. If the user selectes another control in the same combobox the control should be removed from the visualtree and the next control should be downloaded and displayed. If the user changes the selection in a different combobox the corresponding control should be loaded again only in this specific region, with perhaps different data.
And to make it a little more interesting - as this is some kind of dashboard one can change the layout from five regions to - for example - ten regions.
I've seen the video "MVVM with MEF in Silverlight Video Tutorial Part 2: Plugins and Metadata" ( http://csharperimage.jeremylikness.com/2010/03/mvvm-with-mef-in-silverlight-video_09.html ) but he is using an ItemsControl and is working with Visibility and he only got ONE region. So I think that this technique is not working for me...
Puh, I hope I could make myself clear!
Thanks a lot for any piece of information!!!
Greetings,
Tim.
Glenn Block has a series about using MEF to write a Silverlight Dashboard: http://codebetter.com/blogs/glenn.block/archive/2009/11/30/building-the-hello-mef-dashboard-in-silverlight-4-part-i.aspx
I'm having some fun trying to get my head around some MVP stuf, as it pertains to User Controls. I'm using .NET WinForms (or something close to it) and Supervising Controller pattern (well, I think I am :).
The User Control is itself part of an MVP application (its the View and has an associated Presenter etc). The Presenter is always started first, and it starts the Model(s) and then View(s). The View builds its UI, part of which will be to NEW the UC, which is the View.
Now the (form) Presenter needs to know about the UC Presenter, but I'm thinking that it doesn't know anything about how the View is composed. The form Presenter doesn't, for instance, know that the UC is part of the form's Controls collection, nor should it.
Furthermore, the design experience should not be changed; IOW the dev of the View (form) should just be able to select a User Control from the toolbox and drop it on a form.
So, on to my questions. Firstly, are my assumptions above correct? Somewhat misguided? Messed up? WTF are you thinking?
Secondly, is it right (enough?) to have the form View invoke the UC View, and the form Presenter invoke the UC Presenter and have some mechanism to tell the UC View what its Presenter is? This breaks my "Presenter first" rule, but I'm not sure how else to do it.
Any other thoughts, suggestions, comments gladly accepted.
-- nwahmaet
A presenter should be thought of as "autonomous state" in the presentation tier. This means that it is responsible for ensuring that the view's presentation of the model's state is in sync. The reason I bring this up is because the "pattern" of MVP often gets lost in the dogmatic view of how things should be separated. It seems that this is one reason Martin Fowler decided to try to clarify the terminology around the MVP pattern.
My favored flavor of MVP is the passive view, so my answer is based off of that.
I implement composite user controls and forms very often using the passive view pattern. There are essentially 3 different configurations:
One presenter for all user controls in the hierarchy. Flatten the view using an interface.
One presenter for each user control in the composite tree. Each parent presenter is responsible for instantiating and initializing its child presenters. The user controls are created at design time, and are able to function without a presenter (with no presentation behavior)
One presenter for each user control in the composite tree. All of the presenters are loosely coupled through a higher level controller class. The controller class is responsible for construcing the presenter, wiring them up, and coordinating their events.
Although it is a solution of last resort for me (because of its complexity), I think that the last option is the solution that you are looking for.
I've been running up against this exact problem for several months in an application I'm working on. The conclusion that I've very recently come to is that in many cases it might be impossible to apply the MVP pattern at both the window AND user control levels, without "breaking" the pattern.
My thought on it is that the user control is part of the view implementation, and the presenter should not know what is going on inside the view implementation, which means that the window-level presenter by extension should not know about the user control's presenter, and hence there should be no communication between them, including instantiation of the latter by the former. It might be argued that the user control's presenter is part of the window view implementation, and so the window view may instantiate the user control presenter. But it cannot inject the model classes that the presenter needs, because the view isn't supposed to be aware of them.
The conclusion that I think I am arriving at is that ALL user controls are view-implementation-specific, and so should be contained completely within the view silo of the larger pattern. As such, they don't get to have their own presenters... At least not bundled up with the control implementation itself. Instead they should be manipulated indirectly by the parent window's presenter, via pass-through fields exposed on the view interface. In short, the user control is exposed to the presenter not by its own interface, but rather via a common pass-through interface implemented by its parent view. Call this a "partial view interface".
Your presenter can then contain instances of a re-usable sub-presenter class which works only with this partial view interface, and the relevant pieces of the model. This will allow you to avoid re-writing the presenter code to translate from the model every time you need to use the control, AND it prevents the window view from needing to know about the model in order to pass info through to the control's presenter.
What this effectively does is it further separates the user control, as a module, from your data model. This makes sense if you think of a user control, as a whole, as an element of the view implementation. As a re-usable unit, it is a piece of view functionality, and no part of it should be tied to your data model.
Your questions is general that a variety of schemes could apply.
In this case my guess is that you should look at Observer Pattern.
You have a interface that anything that uses that view would implement. Then it would register itself when the application initializes with a collection of those interfaces. Any command that needs to update that view would traverse the collection notifying that each view should be updated.
Unlike typical examples the views would be User Controls. You have the flexibility of making any UI element implement that interface so you could use dialogs, full forms, etc in addition to your User Control.
Finally remember the User Control is NOT the view but the implementation of the View. Whatever scheme you adopt you can define what the View as deep as you want and have the User Control implement that interface.