Empty Interactors on Query-Only-UseCases?

[Julian Seeger]

Hopefully I'm missing something but when applying clean architecture in the real world (in web projects) it often occures to me that the majority of my UseCases are based on the display of data (query only).

A typical Interactor looks something like this (php in this example):

public function execute(SomeInteractorRequest $request)

{

    $someEntities = $this->repository->find($request->getFilter());

    $responseModel = $this->someEntitiesToSomeResponseModel($someEntities);

    return $this->presenter->present($responseModel);

}

Initially, I thought that the main purpose of interactors is to contain the (application dependent) business rules ... but there is no business rule in here.

The Interactor only calls a repository and transforms the entities to a response model (which I often do by calling some kind of entity -> array converter or entitiy->genericDto converter in favor of not repeating myself).

The real logik here may be the filtering of the entities. But there is no point in doing the filtering inside the interactor because noone would fetch the whole database to get a handfull of entites filtered out manually.

When you compare 20 of these interactors, they all look pretty much the same. So I'm producing a bunch of interfaces and extremely boring to test interactors with an increasing feeling that interactors are completely useless for queries.

Now imagine the controller would call the repositories directly (through their interfaces of course). When changing the delivery mechanism, it's the same effort to call the interactor as it is to call the repository. And we dont't have to create an endless list of equal interactors.

So my questions are:

1.) Should my interactors contain more logic than they do now?

2.) Is there a better way to do query-only-requests in clean arch then with a bunch of these (nearly) empty interactors?

3.) How would my architecture be harmed if I would skip these interactors and directly call the repositories from the controllers?

[Caio Fernando Paes de Andrade]

I don't see any harm in calling directly the gateway when there's no logic involved. However, I think this is very rare, not to say this has never happened to me (I'm not entirely sure).

Sometimes the logic is sort of buried and hidden in the gateway, like sorting and filtering a list for example. This may look like there's no business logic involved, but the validation of the sort and filter fields often has a business logic part that belongs to the problem domain and shouldn't be in the gateway at all.

For example you can only filter a booking list by customer given a valid customer, or you can only sort by status given a valid status. Both are domain concepts, and although the use case object will have to call the gateway to verify if those IDs are valid, the actual validation and calling the present errors methods on the presenter belongs to the use case object, in my opinion (I would love to see if people disagree with that and why).

So I haven't actually written many empty use cases because some parameter validation always has to do with the domain problem, belonging to the use case object.

Caio

Sent from my iPhone

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.