4

I'm designing an application using the MVP pattern, but a few of the edge cases for the system rely on communication between multiple presenters.

View 1 calls Presenter 1 which does Operation A returning Result X.

View 2, View 3, and View 4 are all interested in Result X. They each have their respective presenters, and can each respectively do Operation A and get Result X.

Our application has a MainView and a MainPresenter which effectively just house the other views and presenters.

One of the solutions was to give the MainPresenter references of Presenter 1, Presenter 2, Presenter 3, and Presenter 4. And having the result of Operation A call the other presenters.

Another was to implement a Facade layer that holds references to other presenters and it facilitates the other calls.

How have you handled this situation?

5

In my experience, if a result is needed in multiple places in the user interface, this suggests to me that the method for calculating it is a universal business rule, and therefore that rule has no business being implemented in a single presenter: it should be part of the domain model, instead. At that point, no communication between presenters is needed, other than that they all reference the same domain model.

  • Interesting. My company is very headstrong on keeping models anemic, so all of our business logic is typically in presenters. Thanks for the response! – Cameron Nov 10 '14 at 22:52
  • 3
    I've never understood the desire to separate domain logic and domain data. Martin Fowler has a good article on anemic domain models, which he considers an anti-pattern. – Jules Nov 11 '14 at 1:11

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.