Clean Architecture - Controllers and Presenters

Question

I am having a hard time trying to wrap my head around the relationship between Controllers and Presenters in Uncle Bob's Clean Architecture.

In most of his videos, he talks too little about controllers, and a fair amount about presenters. The knowledge available online isn't helping me much either, because there are too many of "my own" versions of clean architecture, which may or may not be correct.

What I am failing to understand is, most of the images, don't have a connection between the controller and the presenter, whether it is a "use arrow" or "inherits arrow", it's not there. There is, however, a single example where it's connected:

(Martin, R.C. Clean Architecture; p84)

This is the only image I can assume that there is an inheritance relation between controllers and presenters. And it makes sense to me. However, the User sits on the outer layer, and interacts with the Views layers only. So, in this sense, sending a form data would reach the controller through the presenters (due to inheritance/implementations)... is this assumption right? I couldn't find any confirmation of that, sorry if I am being a potato.

Images like this one below made me think that there is no relation between them, and are instead made through the interactors, which I am miserably failing to understand if that's the case. Because how would the controllers even be triggered if that's it? Since the interactors have no understanding of what is outside of the boundaries. AND the users can only interact with the views.

(Martin, R.C. Clean Architecture; p196)

Thanks in advance, and again, sorry if it's a dupe, I've read a lot and still am failing to wrap my head about this. So, my questions:

1. Is my first assumption right? Presenters implements/extends controllers?
2. If not, then, can someone explain me the data-flow with some examples?

Interesting examples I would like to understand is:

• User sends form data. Simple as that. Starting by clicking a html button (which sits in the view), passing through all the architectures, and going back to the view with a "Success/Error" msg popped at some alert dialog.
• User gets notified of a change. Instead of implementing a periodic "get" in the presenters, how would a data layer notify the available views (web/smartwatch/app/desktop) when a change happened there. Think something dangerous like, a sudden peak in the sensor data of a bridge pillar.

Thanks.

Answer 1

1. Is my first assumption right? Presenters implements/extends controllers?

Nope.

Lets read some text from the same page as Fig. 8.2

Open arrowheads are using relationships. Closed arrowheads are implements or inheritance relationships

Clean Architecture - page 84

The closed arrowhead isn't pointing at a controller. It's pointing at an interface in the controller component. One that isn't even named controller. It's named Financial Report Presenter <I>.

If you want to ignore the class level and focus on the component level then the very next figure is worth looking at:

This is the exact same design. But this diagram is focused on the component level. Here you don't find any closed arrow heads. This really isn't about that anyway. This is about the direction of dependency. This isn't saying what uses what vs what implements what. This is saying all such arrows must point this way to protect inner components from change.

It's meaningless to talk about components implementing other components when such components are made of many classes doing god knows what. As proof, note that the Database Component has classes that point to the Interactor Component classes with both kinds of arrows.

2. If not, then, can someone explain me the data-flow with some examples?

The fundamental difference between figure 8.2 and figure 22.2 is that 22.2 resembles Command Query Responsibility Segregation. I have illustrated the flow of control of 22.2 before, which closely follows the data flow, so I'll spare you going into that here. However, Figure 8.2 is a new challenge. It is not the same design. Here's its flow of control:

That should give you an idea of the data flow. <DS> means Data Structure. When flow of control first hits them they're being created. Later it means they are being read. Same with the entities. The data flow is mostly the same. The difference is the controller passes the response to the presenter.

<Missing Web Input Rant>

Yes, this is a different design. If you were expecting the web to start things here I'm sorry but that's not what this is. The only way the web kicks this off is if the web is coming in from something not depicted in this design.

I know, when I first looked at this I thought it was weird too. I've come to imagine this as a command line app that you just launch when you want a report. It's not that it has to work that way. But, well, we just launch into the controller without any mention of the web despite the presenters making a big fuss about the web. Why? It's not clear. Uncle Bob doesn't say anything in the book to explain this.

However, we know it works this way because, in addition to kicking off a controller not being a presenters or a views job, we can see from the diagram that they don't know the controller exists. They simply can't call it. Our story has to start with the controller.

</Missing Web Input Rant>

Anyway, the big difference between this (figure 8.2) and figure 22.2 is indeed that the controller knows about the presenter. That means in 8.2 the response can be returned to the controller. In 22.2 the controller got nothing back and didn't have to even know what a response was. I believe 22.2 is less coupled. But 22.2 isn't the only way this can be done. Clean Architecture wont drive you to exactly one design. It just sets up a few rules to follow while creating your design.

User sends form data. Simple as that. Starting by clicking a html button (which sits in the view), passing through all the architectures, and going back to the view with a "Success/Error" msg popped at some alert dialog.

It just has to get to the controller somehow. Sorry but this really isn't depicted in these designs.

User gets notified of a change. Instead of implementing a periodic "get" in the presenters, how would a data layer notify the available views (web/smartwatch/app/desktop) when a change happened there. Think something dangerous like, a sudden peak in the sensor data of a bridge pillar.

This really isn't much of an issue with 8.2. Control flow gets into the views just fine. But if you're really asking about 22.2 here then yes. I've actually talked about this same issue before.