Correct Use of Model in Presenter with MVP-VM Design Pattern
I am self-studying the View Viewer View Model Design Pattern in preparation for joining a new project that will use the pattern with WinForms (NOT WPF).
In my research, I see different uses of the pattern when using the Presenter. Some sites I've seen go through the constructor of the ViewModel as well as the view, another pass in the models as an interface plus the view, and finally another just a view with the model being created in the presenter class.
With the different ways that I show, my question is, what is the correct presenter implementation, should it be like MVP with view and model passing, or does it not matter what style is used?
thank
source to share
Short Answer: It doesn't matter in my opinion as long as you stay consistent and make sure you separate the parts for testing.
You will come across many different articles for two main reasons.
First, there are two main approaches to MVP (traditional):
These links are taken from a large and incomplete series "Create Your Own CAB" by Jeremy Miller. There is also this article on MSDN for further reading.
Two, there are also two main ways of building:
- Leading first
- View first
As you can imagine, one means you start with a Presenter, which then requests / creates a view, or vice versa. There are various measures, and none of them are "wrong".
The main driver for this decoupling is unit testing. If your decoupling allows you to test things like abstraction of implementations and separation of concerns, then you haven't done it "wrong".
Your hybrid MVP-VM approach is also not wrong, but you need to analyze the roles that play and the responsibilities contained in each section of the approach.
I did exactly the same thing as before, teaching this model myself. I got stuck in some kind of learning deadlock due to all the different approaches that have been on the internet, I was constantly worried that I was doing something wrong.
Then I realized that I was very worried about the specific implementation of the pattern. The point of the pattern is not its implementation, but the goals it is trying to achieve and the problem it is trying to solve. MVP is a decoupling and separation of concerns approach to the UI layer and is especially suited to WinForms. It shares this goal with MVVM and MVC. Stick to tenants and ignore differences in implementation details and you will be fine.
I have an old sample app covering this educational journey. There is a lot of bootstrap code in WinForms that needs to be generated in the background to manage things like show / hide views, navigation, create / delete presentations, etc.
source to share