How do I set up MVP for a Winforms solution?

Question

I have used MVP and MVC in the past, and I prefer MVP as it controls the flow of execution so much better in my opinion.

I have created my infrastructure (datastore/repository classes) and use them without issue when hard coding sample data, so now I am moving onto the GUI and preparing my MVP.

Section A

1. I have seen MVP using the view as the entry point, that is in the views constructor method it creates the presenter, which in turn creates the model, wiring up events as needed.

2. I have also seen the presenter as the entry point, where a view, model and presenter are created, this presenter is then given a view and model object in its constructor to wire up the events.

3. As in 2, but the model is not passed to the presenter. Instead the model is a static class where methods are called and responses returned directly.

Section B

In terms of keeping the view and model in sync I have seen.

1. Whenever a value in the view in changed, i.e. TextChanged event in .Net/C#. This fires a DataChangedEvent which is passed through into the model, to keep it in sync at all times. And where the model changes, i.e. a background event it listens to, then the view is updated via the same idea of raising a DataChangedEvent. When a user wants to commit changes a SaveEvent it fires, passing through into the model to make the save. In this case the model mimics the view's data and processes actions.

2. Similar to #b1, however the view does not sync with the model all the time. Instead when the user wants to commit changes, SaveEvent is fired and the presenter grabs the latest details and passes them into the model. in this case the model does not know about the views data until it is required to act upon it, in which case it is passed all the needed details.

Section C

Displaying of business objects in the view, i.e. a object (MyClass) not primitive data (int, double)

1. The view has property fields for all its data that it will display as domain/business objects. Such as view.Animals exposes a IEnumerable<IAnimal> property, even though the view processes these into Nodes in a TreeView. Then for the selected animal it would expose SelectedAnimal as IAnimal property.

2. The view has no knowledge of domain objects, it exposes property for primitive/framework (.Net/Java) included objects types only. In this instance the presenter will pass an adapter object the domain object, the adapter will then translate a given business object into the controls visible on the view. In this instance the adapter must have access to the actual controls on the view, not just any view so becomes more tightly coupled.

Section D

Multiple views used to create a single control. i.e. You have a complex view with a simple model like saving objects of different types. You could have a menu system at the side with each click on an item the appropriate controls are shown.

1. You create one huge view, that contains all of the individual controls which are exposed via the views interface.

2. You have several views. You have one view for the menu and a blank panel. This view creates the other views required but does not display them (visible = false), this view also implements the interface for each view it contains (i.e. child views) so it can expose to one presenter. The blank panel is filled with other views (Controls.Add(myview)) and ((myview.visible = true). The events raised in these "child"-views are handled by the parent view which in turn pass the event to the presenter, and visa versa for supplying events back down to child elements.

3. Each view, be it the main parent or smaller child views are each wired into there own presenter and model. You can literately just drop a view control into an existing form and it will have the functionality ready, just needs wiring into a presenter behind the scenes.

Section E

Should everything have an interface, now based on how the MVP is done in the above examples will affect this answer as they might not be cross-compatible.

1. Everything has an interface, the View, Presenter and Model. Each of these then obviously has a concrete implementation. Even if you only have one concrete view, model and presenter.

2. The View and Model have an interface. This allows the views and models to differ. The presenter creates/is given view and model objects and it just serves to pass messages between them.

3. Only the View has an interface. The Model has static methods and is not created, thus no need for an interface. If you want a different model, the presenter calls a different set of static class methods. Being static the Model has no link to the presenter.

Personal thoughts

From all the different variations I have presented (most I have probably used in some form) of which I am sure there are more. I prefer A3 as keeping business logic reusable outside just MVP, B2 for less data duplication and less events being fired. C1 for not adding in another class, sure it puts a small amount of non unit testable logic into a view (how a domain object is visualised) but this could be code reviewed, or simply viewed in the application. If the logic was complex I would agree to an adapter class but not in all cases. For section D, i feel D1 creates a view that is too big atleast for a menu example. I have used D2 and D3 before. Problem with D2 is you end up having to write lots of code to route events to and from the presenter to the correct child view, and its not drag/drop compatible, each new control needs more wiring in to support the single presenter. D3 is my prefered choice but adds in yet more classes as presenters and models to deal with the view, even if the view happens to be very simple or has no need to be reused. i think a mixture of D2 and D3 is best based on circumstances. As to section E, I think everything having an interface could be overkill I already do it for domain/business objects and often see no advantage in the "design" by doing so, but it does help in mocking objects in tests. Personally I would see E2 as a classic solution, although have seen E3 used in 2 projects I have worked on previously.

Question

Am I implementing MVP correctly? Is there a right way of going about it?

I've read Martin Fowler's work that has variations, and I remember when I first started doing MVC, I understood the concept, but could not originally work out where is the entry point, everything has its own function but what controls and creates the original set of MVC objects.

Answer 1

A lot of what you present here is very reasonable and sound. Some of the choices are going to depend on specifics with the application and which one "feels" right. As is the case most of the time, there isn't going to be one right answer. Some of the choices will make sense here and those choices could be completely wrong for the next application and circumstances. Without knowing some of the specifics of the app, I think you are on the right track and have made some sound, thoughtful decisions.

For me, I feel that the Presenter should almost always be the entry point. Having the UI as the entry point puts too much logic in the UI and takes away the ability to substitute a new UI without big coding changes. And really that IS the job of the presenter.

Answer 2

We use a modified form of MVP on our .NET 2.0 Winforms app. The two pieces we were missing were a modified adapter of the WPF ViewModel, and adding data binding. Our specific pattern is MVPVM.

We wire in as presenter-first in almost every case, except for custom usercontrols, which are wired in view-first for designer friendlyness. We use dependency injection, code-generated ViewModels, BDD for the presenters, and TDD/TED for the model.

The VM's are just a massive, flat, wad of properties that raise PropertyChanged when they're changed. It was very easy to generate these by code (and their associated exercising unit tests). We use them for reading and writing to user-interactable controls, and controlling enabled statuses. The ViewModel is coupled with the View, since we use databinding for damn near everything else.

The View will occasionally have methods on it to accomplish things that the VM can't. This is usually controlling visibility of items (WinForms can be picky about it), and things that refuse to be databound. The View always exposes events like "Login" or "Restart", with appropriate EventArgs to act on user behaviors. Unless we've had to use a hack like "View.ShowLoginBox", the View is completely interchangable as long as it meets the general design requirements.

It took us about 6-8 months to nail down this pattern. It has a lot of pieces, but is very flexible and extremely powerful. Our specific implementation is very asynchronous and event-driven, which may just be an artifact of other requirements rather than a side-effect of the design behavior. For instance, I added thread synchronization to the baseclass that our VM's inherit from (which simply exposed an OnPropertyChanged method to raise the event) -- and poof, now we can have multithreaded presenters and models.

Answer 3

I am using a version of PureMvc that's been modified for .Net, and then extended by myself.

I was used to PureMvc from using it in Flex applications. It is a bare bones type of framework so its fairly easy to adapt if you want to customize it.

I took the following liberties with it:

• Using reflection I was able to get private properties in the view-mediator to go out into the form class and grab the (private) reference to each control I was mediating.
• Using reflection I can auto-wire the controls to the event signatures in my mediator, which are generic, so I just switch on the sender parameter.
• Normally, PureMvc wants derived mediators to define their notification interests in a function that will return an array of strings. Since my interests are mostly static, and I wanted to have an easier way to see the mediators interests, I did a modification so that the mediator can also declare its interests by set of member variables with a particular signature: _ _ _<classname> _ <notification-name>. This way I can see what is going on using the IDE member tree instead of looking inside a function.

In PureMvc, you can use a Command to be the entry point, a typical Start command would set up the Model to the extent it could, then create the MainForm, create and register the mediator for and with that form, then do Application.Run on the form.

The mediator for the form would be responsible for setting up all the sub-mediators, some of this can be automated by, again, using reflection tricks.

The system I am using is drag/drop compatible, if I understand your meaning. The actual form is all created in VS, but my experience is only with forms that have statically created controls. Things like dynamically created menu items seem feasible with a bit of tweaking of the mediator for that menu or submenu. Where it would get hairy is when the mediator had no static root element to be hooked onto and you got into creating dynamic 'instance' mediators.