4

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:

1 (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.

2 (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.

5
  • Can you source the first image? I believe it shows something quite different from the second image. – Euphoric Feb 2 at 6:41
  • You sure you have watched his talks? Because he explicitly talks about the request flow here: youtu.be/o_TH-Y78tt4?t=1434 Also, I do fainly remember him saying that his usage of terms "controller" and "presenter" are not same as those in MVC/MVP. He is just using the names for lack of better terms. – Euphoric Feb 2 at 6:49
  • Hi @Euphoric thank you for you response. I source the images. I watched his talks and I did understood that "Controllers" are not the same one as MVC. They are meant to work the input request data models... however, as you can see in the talk you mentioned, the user is sitting outside the 'delivery mechanism' there, and the flow he shows, when using the controller, 'pass through the presenter' to 'use the controller' (since the wavy lines are on the controller position)... I couldn't find evidence that the user is using the controller directly. Thank you. – Bruno Tacca Feb 2 at 11:08
  • @BrunoTacca those slides resemble figure 22.2 more than figure 8.2. Note the two boundary interfaces. – candied_orange Feb 2 at 11:18
  • Also @Euphoric, I just noticed your reply on another topic and you nicely placed an Orchestrator there in the image 22.2, which is the concept that I was missing. (Without the orchestrator calling the presenter of course) Thank you too. – Bruno Tacca Feb 2 at 12:10
7
  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:

enter image description here

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.

  1. 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:

enter image description here

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.

7
  • Wonderful @candied_orange. You definitively got my point there, your <rant> was exactly my <rant>. So, the user interacts with the controller to start an input flow, and, the presenters interacts with the user to show information through the views, an output flow. However, does this means that the views has knowledge about the controller functions?, since the input flow must start there. What I mean is, the "web view" in 8.2 or the "view" in 22.2, will have an "use arrow" with the controller? Thank you. – Bruno Tacca Feb 2 at 11:32
  • 1
    @BrunoTacca Something, somewhere, has to know about, and talk to, the controller for this to work. But nothing in these diagrams tells you what. It doesn't have to be the view. Sometimes a view is just part of a UI. A UI might have other parts that know about the controller. It's just not in these diagrams. – candied_orange Feb 2 at 11:53
  • 8.2 seems biased by Martin's own experience with those old and former systems that he had to provide with support for different I/O interfaces. Way before the boom of the WWW and the web applications. If you read C.A he does mention a few to illustrate why the I/O and DB should be in the outer layers and invert the dependency (outer layers depending on inner layers interfaces or contracts). – Laiv Feb 2 at 12:40
  • @Laiv I honestly can't tell if you're challenging something I've claimed or if you're just mentioning something you've noticed. If you see room for improvement here please let me know. – candied_orange Feb 2 at 12:46
  • @candied_orange no claim at all. Just giving context to figure 8.2. If the OP didn't read the book, it might have been losing U.B perspective for him to draw the presenters. It's been a while since the last time I read the book, I just remembered about his past experiences and how he used'em to illustrate his reasonings. He also used these diagrams as a summary of all the ideas he introduces progressively during the reading. – Laiv Feb 2 at 12:58

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.