Presenter vs Returning Response Objects

[Christian B]

Hello guys,

I am currently reading a lot about Clean and Hexagonal Architecture. 

I believe they are very similar because they are both use case driven.

The only difference i saw yet is, that Uncle Bob uses Presenters that the Interactors uses.

My Question: Why?

Maybe i missed the purpose of a Presenter, but why do i need a presenter, and not just return a Response Object in the Interactor implementation?

Is it because i would create a dependency between the Controllers and the Use Case Responses? 

In a PHP web application, i imagine something like this (without Presenter):

<?php

namespace Some\Controller;

class UserController extends Controller {
    public function registerAction() {
        // Build the Request object
        $request = new RegisterRequest();
        $request->name = $this->getRequest()->get('username');
        $request->pass = $this->getRequest()->get('password');

        // Build the Interactor
        $usecase = new RegisterUser();
       
        // Execute the Interactors method and retrieve the response
        $response = $usecase->register($request);
       
        // Pass the result to the view
        $this->render('/user/registration/template.html.twig', array('id' => $response->getId());
    }
}

I don't see any reason for a presenter, tho i believe it is better to have one (or else Uncle Bob would not say us so :) )

[witali mik]

i gues the presenter part have something todo with C languages. In PHP you have just the Browser as Output in C you can use different renderer, for example some GUI which is made by a GUI Builder or using DirectX or OpenGL or Console. (well php can use Console output as renderer as well, but this is not the common way)

But i just assume this, i dont really know :/

[Uncle Bob]

The purpose of the presenter is to decouple the use cases from the format of the UI.  In your example, the $response variable is created by the interactor, but is used by the view.  This couples the interactor to the view.  For example, let's say that one of the fields in the $response object is a date.  That field would be a binary date object that could be rendered in many different date formats.  The wants a very specific date format, perhaps DD/MM/YYYY.  Whose responsibility is it to create the format?  If the interactor creates that format, then it knows too much about the View.  But if the view takes the binary date object then it knows too much about the interactor.

The presenter's job is to take the data from the response object and format it for the View.  Neither the view nor the interactor know about each other's formats.  

[Christian B]

Thanks!

[daniphp]

How would you remodel the code using the presenter?

[daniphp]

Dear Uncle Bob,

most PHP frameworks are imposing a MVC style. A Presenter isn't usually a familiar concept. 

1.In case the response is very simple and doesn't need formatting is it acceptable to use the response without a presenter?

2.If the presenter will decouple the interactor from the view isn't the presenter coupled with the interactor?

3.A presenter creates a "model" from the response after applying some formatting, but if the response and model used by the view are identical is the code duplication justified?

Thank you.

[Michel Henrich]

daniphp,

I tend to think of the M in MVC as my "presenters".

When the concern of the delivery layer is just to present data in the View (as MVC is originally intended for), then the models are really just for presentation. And in my opinion, they are the ones responsible for formatting.

For instance, imagine a simple "ReadEmployee" use case and an interactor for it. This interactor will respond with the information of a specific employee in a general way, which is not ready for presenting in a web page. You then instantiate a Model, in the delivery layer, that will hold the interactor response, and based on it, will provide the information that the View needs to present, already with the correct format.

[witali mik]

Ah thx for the hint, i did this part inside my interactor and currently didnt liked it really well

https://github.com/Opentribes/Core/blob/develop/src/Interactor/CreateCity.php#L49

cause i violated the inversion of control principle there.. i gues i require an abstract View class(which you call presenter) and do the implementation inside my delivery layer and pass that view into interactor.

on the other hand, i created my response as a simple Data Structure, just a class with public properties. this allows me to speak with the front end developers. i can easily say

"if you open the URL xyz in your browser a template file xyz.mustache will be rendered and you have following placeholders for your template " and show them my response class

but at the end, response just have public properties and my template engine has the helper methods to format/translate/convert values and the front end guy do care about the output

[Mike Schmidt]

Hello,
i have written a small CustomerService (Java, Spring MVC) Clean Architecture sample project. It implements the following logic:

1. the controller create the presenter and pass the modelMap into it
2. the controller create the interactor and pass the presenter instance into it
3. the controller call the interactor (separation via his boundary)
4. the interactor read all the customer data via a entity gateway implementation from a database (separation via the entity gateway boundary)
5. the interactor call the presenter (separation via his interface)
6. the presenter convert the customer raw data to the format that we want to show to the customer and put it into the modelMap
7. the interactor finished
8. the controller finished
9. the front controller (handeled by Spring?) creates the html page, using the jsp page (the view) and the modelMap - filled by the presenter

As far as I understand, I followed all the rules from the Clean Architecture. But I don't understand, why the interactor has to call the presenter. The interactor can for eaxmple also return the raw data to the controller and then the controller can call the presenter to convert the raw data to view format. In this case, only the controller knows about the data transformation. But isn't it the job of the delivery mechanims to transform the data that we want to show to the customer?

I would be very happy if I can better understand why the interactor and not the controller should call the presenter?

Many regards,
Mike

[Valentin Tudor Mocanu]

The purpose of the presenter imho should be also orchestration, but for presentation layer. That mean must not perform specialized, detail task as formatting the dates, but rather delegate this task to other classes ("baby presenters").

- view: responsibility =  display

- model: responsibility = data available for display 

- presenter:  responsibility = orchestration: view, model other specialized  and interactors 

For very simple presentations, ok, we can use presenter to other tasks, but ALREADY has a responsibility : orchestration for presentation level.