3

Coming up to speed on the MVP design pattern and I have a gap in my understanding. The consensus seems to be to design a 1:1 relationship between Presenter and View. This makes sense -- but how would this work when state must be passed from one view to the next.

For example, imagine the following two View application;

1) Login Form, 
2) Data Entry Form.

Assume the Data Entry Form requires the credentials entered into the Login Form View.

Does the application require another layer above the MVP that orchestrates the Views? A layer that would handle showing the next (or previous) View? And how should the separate Views share data? Should the the Data Entry Form Presenter have access to the Login Form Model?

Or does one Presenter create the next P/V in sequence. Meaning, after a user successfully logs in, does Login Form Presenter create the Data Entry Form View and pass in the credentials?

My question is fundamentally the same one raise by Multi-page app using passive-view MVP with multiple presenters - what is the most appropriate way to handle page changes? but that question is unanswered.

If it matters, the project is a WinForm written in VB.Net.

  • Have a look at the structure of this WinForms MVP app. Its written using C#, but the differences between VB.NET and C# are pretty much irrelevant for this sort of thing: markheath.net/post/model-view-presenter-winforms – Ben Cottrell May 2 '17 at 16:47
  • I agree that C# & vb.net are not relevant to the discussion...but...I'm not a C# developer. I glanced at the code but there's enough going on that I can't see the answer to my overarching question -- which is how do you communicate state in an MVP design pattern. I'm leaning towards a service layer above the MVP pattern that manages the whole process. But I was trying to see how others solved this problem. – user590028 May 2 '17 at 18:31
  • In that example, the communication between various Presenter classes happens via the EventAggregator. the EventAggregator pattern is equivalent to a message broker which passes state/information between presenters using various POCO 'message' classes. Each presenter can Publish or Subscribe to different message POCO types which its interested in. You could achieve exactly the same thing with a Single-instance service class instead of EventAggregator though. – Ben Cottrell May 2 '17 at 19:00
  • Thanks Ben. If you post this as Answer, I'll mark it accepted. – user590028 May 2 '17 at 20:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.