0

Whereas there seems to be a lot of information on the Internet about what the presenter both is and does, there doesn't seem to be a whole lot that specifically describes where to put it in a multi-layered architecture. My guess would have been the business layer, but very recently I read something that said the business layer should deal only in domain-/system-wide logic, not anything that's giving commands out to control a specific application's UI.

I'm not too sure what difference there would be between what a business layer deals in and what a controller/presenter deals in, other than that a controller/presenter would somewhat connect business logic with UI logic.

So, for example, if there are separate layers for UI, business, communication, and data access - or if there is any similar setup with a slightly different choice of layers that is not simply three layers for model, view, and controller themselves - where would you put a presenter class? Would it invariably go in the business layer? If you do that, do you have to go out of your way to minimize chat between it and the view interface to mitigate overhead from the layering?

Improve this question
12
  • 1
    model -> controller / repository -> presenter (prepared data) -> view (UI) Usually presenters are so specific to preparing the data for visualization that they do not involve an overhead. The presenter just wraps the model (or repository) for showing it.
    – Heroselohim
    Oct 7, 2016 at 13:02
  • 2
    If you are implementing MVP, it goes (conceptually) in UI layer, as Controllers do on MVC patterns. MVP is considered a GUI design pattern Presenters are intended to be a handler of UI events. To operate with the model and to retrieve the UI based on the results of these operations. The problem comes when we tie tightly these operations to business rules. In an ideal scenario (no matter the pattern), the business has nothing to do with UI and it's requirements. Business should be agnostic.
    – Laiv
    Oct 7, 2016 at 13:08
  • So the presenter is almost nothing more than a wrapper around the UI that just sort of routes the UI interface's input and output back-and-forth to the rest of the software without worrying about any of the underlying rules or anything? There would generally be at least one or two full layers between the presenter and the model in that case? For some reason I was thinking the presenter was more of an overall hub.
    – Panzercrisis
    Oct 7, 2016 at 13:18
  • 1
    Check out this post stackoverflow.com/questions/2056/…. I have read it and it summarises well the pattern. It also explains the conceptual differences between MVP and MVC.
    – Laiv
    Oct 7, 2016 at 13:46
  • 1
    @Laiv Thanks for the link! Part of the problem I'm having is that different people seem to contradict each other about what the differences are, and a lot of times they're not really describing it in very clear terms. For example, one will say the view talks to the model only in MVC, not in MVP, and another will say it's the other way around or that it's a choice in MVP. Or one will say it's only one presenter per view, and another might say that's not always the case.
    – Panzercrisis
    Oct 19, 2016 at 13:27

1 Answer 1

Reset to default
1

My preference is for @Laiv to post an answer, since he/she essentially answered this in the comments, but until then, I'll post this as the answer:

Presenters go in the UI layer.

Improve this answer

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.