Use-Case initiation and inputs

[Stefan Bradl]

Hello coders,

We recently had a discussion at work regarding how a client initiates an use case and how it passes certain inputs to the use case.

We have the following imaginary example use case: The user wants to generate a report based on some item.

Now we discussed two ways of how the client (from a source code perspective) starts/executes the use case.

1. A button is clicked, inside the event handler a dialog is opened where the user selects the item needed to generate the report. Now this item is passed to the interactor as an input.
   
2. A button is clicked, inside the event handler the interactor is called. The interactor itself has a callback mechanism to ask the client for the needed item.

Both methods have pro's and con's... The first approach seems more natural for some kinds of use cases (e.g. for an use case "CreateUser" you would expect the username to be an input passed to the interactor) while the callback approach seems very appropriate for others.

The callback approach would be nice for an "Login" use case.

Username and password are passed as inputs to the interactor. The interactor validates the credentials and finds out that the user has enabled 2-factor authentification. So the interactor executes a callback to ask the client for additional information. Without the callback mechanism this use case had to be split in two parts, one the client side the first part must be initiated, the response must be checked, and then the second part would be started.

We would like to have a guideline which approach is "the better" one or at least which should be used in which scenarios.

What do you think?

[Péter Böszörményi]

Well, normally I go with approach 1, because it's simpler. Let's not
complicate the things. Also, it's less dependency, the interactor is not
aware, where the data come from.

The second approach is a tricky one. I guess, the problem is, that
during the executon, the interactor want to interact with it's client.

Let's see how your login example would work in a desktop, and a web
application.

Desktop app.
User enters the username and the password, then clicks on the login button.
The event handler creates the neccesary callback objects, and call the
interactor
The interactor realizes that the user has a 2-factor authentication, and
- through the callbacks - ask the user to provides the necessary
information. Notice, that the interactor runs in the GUI thread, and as
soon calls the callbacks, it will probably blocks the thread. (The
callback probably shows an input screen for the user). This approacy
probably work, I can imagine the GUI toolkits are prepared for such
behaviour.
Finally, the interactor receives the addition credential, and executes
the login.

Now, let's see the web app.
User enters the username and the password, then clicks on the login button.
The browser sends a request to the server, with information.
On the serverside, a controller extract the information, creates the
necessary callback objects, and pass everything to the interactor.
The interactor realizes that the user has a 2-factor authentication, and
- through the callbacks - ask the user to provides the necessary
information. Here, We are still in the request, no answer has been sent
back. But here the callback won't block. In the GUI version, the
interactor was blocked till the user provides all the neccesary
information. Here, it's not the case. The interactor calls the callback,
wich, in turn, send back a response to the user, and that's it, the
request has been already served, the callback can't wait till the user
provides the addition login info.

I think, the problem is, that the use case is to high level. I love the
idea, to drive the whole use from the interactor, and the GUI is only
allowed to response the requests of the interactor, but at the moment I
don't see a good solution.

On 2017-08-16 13:15, 'Stefan Bradl' via Clean Code Discussion wrote:
> Hello coders,
>
> We recently had a discussion at work regarding how a client initiates an
> use case and how it passes certain inputs to the use case.
>
> We have the following imaginary example use case: The user wants to
> generate a report based on some item.
>
> Now we discussed two ways of how the client (from a source code
> perspective) starts/executes the use case.
>

> 1. A button is clicked, inside the event handler a dialog is opened

> where the user selects the item needed to generate the report. Now
> this item is passed to the interactor as an input.

> 2. A button is clicked, inside the event handler the interactor is

> called. The interactor itself has a callback mechanism to ask the
> client for the needed item.
>
> Both methods have pro's and con's... The first approach seems more
> natural for some kinds of use cases (e.g. for an use case "CreateUser"
> you would expect the username to be an input passed to the interactor)
> while the callback approach seems very appropriate for others.
>
> The callback approach would be nice for an "Login" use case.
> Username and password are passed as inputs to the interactor. The
> interactor validates the credentials and finds out that the user has
> enabled 2-factor authentification. So the interactor executes a callback
> to ask the client for additional information. Without the callback
> mechanism this use case had to be split in two parts, one the client
> side the first part must be initiated, the response must be checked, and
> then the second part would be started.
>
> We would like to have a guideline which approach is "the better" one or
> at least which should be used in which scenarios.
>
> What do you think?
>
>

> --
> 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
> <mailto:clean-code-discu...@googlegroups.com>.
> To post to this group, send email to
> clean-code...@googlegroups.com
> <mailto:clean-code...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/clean-code-discussion.

--
Best Regards,
Péter Böszörményi

[Stefan Bradl]

We already implemented the callback approach for desktop and web (using the SignalR framework from the .NET world). Both were quite easy so that is not a problem.