But uncle bob! Why is the database so important for you?

[Julian Seeger]

We know that the Database, like the delivey mechanism, should be kept behind boundaries to keep the core of our application clean from those details. So if both are just plugins, then both should be kept behind the same type of boundary. And “we don’t want to cheat and pass Entities or Database rows“ [http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html] through those boundaries.

But when we add the real world and keep it pragmatic, uncle bob tends to soften this boundary to the Gateway and pass Entities right through it, what makes the GatewayImplementation depend directly on the Entities (http://i.stack.imgur.com/Xvlg0.png). So the Entities are passed through this boundary. Probably because it is easier and saves a lot of time (at least in advance). Time that we would otherwise spend on the transfer of properties from an Entity to the according PersistableEntity or whatever we would call that dto.

What I’m actually wondering about is this: why is the gateway-boundary so soft but the presenter-boundary remains? This just seems completely inconsistent to me. If I don’t want the Interactor to know what the Presenter want’s to pass to the View, then I have to pass all the data of my according Entities to the Presenter to let him decide, what is passed to the View. So whatever I am passing to the Presenter (like a PresentableEntity), needs all the information from the Entity making it some kind of Entity-state without the Entity-behavior. This is the same overhead I would have if the Gateway wouln’t know the Entities. And even if I would pass the Entities directly to the Presenter, the View would still know nothing about the Entities because it only depends on the ViewModel which is created by the Presenter. So the Gateway-Plugins and the Presenter-Plugins should be equally decoupled, shouldn’t they?

Is the probability of multiple Gateway implementations lower than the probability of multiple delivery mechanisms? Probably not. Even in the simpliest webproject I would expect two implementaion groups for the Presenter: Web and the unittests (like some FakePresenters) and two gateway implementations: the “real” Database and some InMemoryFake for the tests. And it has often occured to me that multiple types of gateway implementations were used outside the tests: a more portable sqlite version for dev-environments, a full blown daemonized dbms for the staging- and production-environments and maybe some entities (or their state) even have to be sent with SOAP to some extenal service that would for example manage the user data. On the other hand, if my application can be delivered through http/html, cli and some sort of http/json api, then it’s probably done. Another reason the treat both boundaries (to the Gateways and to the Presenters) equally.

Why is it totally acceptable if the Gateways know the Entities but inacceptable if the Presenters do?

[Jon Reid]

Because if we keep our Presenters ignorant of Entities, they can be reused in different contexts, and easily replaced with other Presenters.

Consider a typical iOS or Android UI where we want to present a series of image URLs with captions. Maybe you initially make it scroll vertically, with each caption below its image. Ah, but there's an ongoing quest for sexier UI to make your app stand out — so the product manager asks you to change it to a carousel. Oh, but only on phones. On tablets, it should be a mosaic-style where images are presented in different sizes.

The initial work of creating a new UI is laborious, but once you have it, you can reuse it or swap it out, or even choose a different presentation depending on the device. And keeping them separate from Entities ensures that your hard work isn't tied down to one app.

- Jon

http://qualitycoding.org/ — Building Quality into iOS Development

[Julian Seeger]

To replace the Presenters, I don't need to be decoupled from the entities. I can always swap out an HtmlShowImagesPresenter with a JsonShowImagesPresenter no metter what the input to them is.

And to address your example: changing a "series of images" with a carousel is probably only a change in the view. As long as the input data remains the same (aka ViewModel), the Presenter isn't affected at all. An even if he is, there is no problem when he depends on the Entities. The only "problem" occurs if I want to change the Entities (or the Entity-Interfaces ^^) and that also applies to the Gateways.

The last part of your response is interesting: You suggest reusing the Presenters in multiple applications.

What I always did is implicitly bind the Presenter to the Interactor. For example the ShowImagesInteractor would need a ShowImagesPresenter (interface) injected and would fill a ShowImagesResponse (model). And if the PresenterImplementation depends on these interactor-specific interfaces of the boundary, it is interactor-specific. And the Interactors are of cours application specific (because they contain the application-specific business rules). So there is no way of reusing the Presenter even if they don't depend on my Entities. How does your Boundary then look like if it can be reused in multiple applications?

I would say that if you want to reuse anything in multiple applications, it would be your entities (because they contain the application-independend business rules). That would be another argument to make more things depend on them because they have to be stable anyways.

[Dave Schinkel]

But hmm, where are you talking about interactors in your initial post?  I don't see anything about passing entities to the Interactor which is critical.

I think that's missing here in the conversation...

[Julian Seeger]

The whole post is about Interactors or to be more specific: about what the interactors pass through boundaries and what they receive through boundaries while they are acting.

The interactors use the gateways to get stuff from the database and the interactors use the presenter to ... well present stuff. These two actions seemed to me to be enough of similarity to question the special role of the database.

[Dave Schinkel]

Gotcha.  For me I'm using a controller to take in the http request for my REST API.  So you're using a presenter on the left side of the boundary and on the right side, the interactor is right there receiving the request??  Do you have boundary interfaces?