Correct use of Model in Presenter with MVP-VM Design Pattern

4
votes

I am self-studying the Model View Presenter View Model Design Pattern in preparation to joining a new project, which will be using the pattern with WinForms (NOT WPF).

In my research I am seeing different uses of the pattern when comes to using Presenter. Some sites I have seen pass in via the constructor the ViewModel object as well as the view, another passes in the model as an interface plus the view, and finally another just the view with instantiation of the model in the presenter class.

With different ways being shown, my question is this, what is the correct implementation of the presenter, should be like MVP with view and model being passed, or doesn't matter what style is being used?

Thanks

1
c#design-patternsmvp

1 Answers

3
votes

Short answer: In my opinion it doesn't matter, so long as you remain consistent and make sure you've decouple the parts for testing.

One, there are two main approaches to MVP (traditional):

Those links are from the great and incomplete "Build your own CAB" series by Jeremy Miller. There is also this article on MSDN for further reading.

Two, there are also two main construction routes:

  • Presenter first
  • View first

As you can imagine, one means you start with a Presenter, which then requests / constructs a view, or vice versa. There are various takes and none of them are "wrong".

The primary driver for this decoupling is unit testing. If your decoupling enables testing through things such as abstracting implementations and separating concerns, then you have not done it "wrong".

Your hybrid approach of MVP-VM is also not incorrect, but you need to review the roles being played and the responsibilities contained within each section of the approach.

I then realised I was worried to much about a particular implementation of the pattern. The point of a pattern is not its implementation, but the goals it tries to achieve and the problem it tries to solve. MVP is a decoupling and separation of concerns approach to the UI layer and is particularly suited to WinForms. It shares this purpose with MVVM and MVC. Stick to the tenants and ignore implementation detail differences and you'll do fine.

I have an old sample application somewhere encompassing this learning journey. In WinForms there is a lot of bootstrapping code you need to create in the background to manage things like showing / hiding views, navigation, creating / disposing presenters etc.