Where are presenters created?

[Imre Kószó]

Sorry if there's already a thread about this, I tried to search for it but didn't find anything.

Trying to build my application, I was re-watching E18 and there is something I don't know the answer for. Who and where creates the Presenter? Either the Controller or the Interactor will need to hold a reference to it in order to present the use case response but I can see no component pointing in the direction of the View component, so nothing to create the Presenter instance.

This made me think it could be referenced and built by something in Main based on the type of use-case response expected.

The thing is, there could be multiple uses of a use-case (not completely sure about this though), for example:

- Use-case: get customers from the system

- In View A we want to display all the customers ordered by their name

- In View B we want to display the top 20 customers by their registration date

The use-case interactor could take some filtering arguments in the request from controllers A and B, but organizing and ordering the data it returns would be handled in presenters A and B for their respective views.

- How would Main know which presenter to fire up?

- Should the controllers build the presenters instead as they will know more about the circumstances? Or would we want to prevent introducing a dependency pointing from the Controller component to the View component (containing the presenter)?

- Should the presenters be build somewhere else? Where?

- I might be absolutely wrong assuming reuse of a use-case but the scenarios look very similar.

- Am I completely missing something?

Thanks in advance!

[witali mik]

I think, a use case is not ment to be reused.. a usecase defines a specific case which exists once, usually a usecase is bound to a role, what you currently need is just a filter possibility in your interactor input port, at the end, your interactor returns a View Object and you render this with your Presenter. So your Controller gets the GUI Request with filter options, you pass them into interactor and return a view.

in your example, you dont have different usecases, you just have different filter/order parameters.

[Imre Kószó]

Thanks for the reply Witalik. When I wrote reusing the usecase I really meant reusing the interactor with some filtering as you suggested. However I disagree with the rest, I think interactors should not return view objects. Presenters are the objects that take DTOs produced by interactors and convert them to View Models that are then passed to the views. At least this is what I got from E18.

[witali mik]

i gues i used View in wrong context :D with a view i mean a View Object.. not the template, i dont see a template as a view.. basicly i just know PHP and i hope this code explains what i mean...

http://pastebin.com/RHxqnsvD

please ignore the parameters in request:D its just ment as example.. maybe the template is a view and the view which returns the interaction is a view model.. i just dont use the right words but i gues we both ment the same

[Jop van Raaij]

Answering the first question, "Who and where creates the Presenter?": the client creates (implements) the Presenter. The Presenter is defined by an interface in your application. When the client (a web framework controller or something else 'outside' your application) calls the interactor to execute an use-case, the client can influence (form of) the output by implementing the Presenter (Open-Closed principle).

Also take a close look at the picture in the right bottom of http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html.

[Imre Kószó]

Thanks guys, I'm checking these links out. So far it looks like it will be the controller's responsibility to instantiate the presenter then.

[Norbert Nemes]

Hello Imre

I think the answer to your question is Main.
If you watch Episode 7 - Architecture, you will find that our good Uncle talks about the plugin architecture, and you actually have diagrams of how the presenter fits into all of this at about 00:48:00.
Also, he makes it clear that what he calls interactors, are in fact controllers, but he didn't want to call them that so we don't confuse the clean architecture with MVC.
(In other words, it makes no sense to have a controller AND and interactor).

The way to do it is like this:
Let's suppose you have an interactor, and a presenter.
The presenter is composed with (has) an InteractorRequest object (it's actually an interface) that it uses to tell the interactor to do somenting.
It also implements an InteractorResponse interface, through which the interactor communicates back its results.
The interactor on the other hand is composed with (has) an InteractorResponse object(interface), and implements the InteractorRequest interface.
Main creates both of them and plugs them into each other like this:

Presenter presenter = new Presenter();
Interactor interactor = new Interactor();
presenter.setInteractorRequest(interactor);
interactor.setInteractorResponse(presenter);

And that's it. Furthermore, there is no reason why a presenter cannot be plugged into several interactors.

Hope it's clearer now.

All the best,

Norbert

[Imre Kószó]

Thanks Norbert, I am experimenting with this problem and it seems like creating in main is indeed a usable solution.

This thread (I only recently found it otherwise I would not have started this one :P) is very helpful: https://groups.google.com/forum/#!searchin/clean-code-discussion/onion/clean-code-discussion/oGW5Ezcnib8/nJVT1x7TwoEJ

[witali mik]

Am Mittwoch, 13. November 2013 16:06:22 UTC+1 schrieb Norbert Nemes:

(In other words, it makes no sense to have a controller AND and interactor).

i would disagree, the MVC Part is using(could use) the Clean Code(Business Rules) part. an interactor is more like an action within a controller, since interactors follow the Command Pattern. a controller is usually a group of commands which should be executed. It does make sence to have a controller and an interactor, since the controller is the replacable part while the application without a specific interactor would not make sense

[Norbert Nemes]

Hello Witali

I have a feeling that we might be talking at cross purposes :)
Uncle Bob defines Interactors (Ep 7 00:42:00) as objects that implement application specific use cases.
That's a controller in my book.
Perhaps it's just semantics, but that's why to me it makes no sense to have a controller between the presenter (also a controller)
and an interactor (controller).

Regards,

Norbert

[witali mik]

Hello Norbert,

i watched this video http://vimeo.com/68215570  there he told Interactors are like Command Pattern. i gues you could either create a controller like interactor which contains methods like "executeThis" ,"executeThat" or "executeWhatever" or you could create an interactor which contains just one execute method und call multiple interactors within an action. like

newBankAccountAction(){

createEmptyBankAccountInteractor.execute();
addInitialAmount.execute();
sendWelcomeMail.execute();
}

where you could combine multiple interactors for different usecases.

since it is not really clear and you have different ways you cannot say that controller cannot exists with interactors ;) thats was just my point

Regards,

Witali

[Norbert Nemes]

Hello Witali

Yes, you are right. Originally I was thinking about the simplest case 1View, 1 Presenter, 1 Interactor for the whole system.
In this case I don't see any point in inserting another controller between the presenter and the interactor, since the interactor would return a data structure with the data to display, and the presenter would just process and display it.
On the other hand, if the system is more complex, I can imagine a facade being put between the presenter and several interactors needed to provide the data.

Regards,

Norbert

[witali mik]

Hello Norbert,

ofc i saw this repository https://github.com/igorw/doucheswag  there the developer, just mapped routes to interactors itselfs and then he has no controllers anymore(he used controller name for the filename of the view).. but if you have a bit more interactors and more usecases for different user roles, i would use a controllers with action