Considering Uncle Bob's Clean Architecture (or Onion Architecture)
Let's say that as a signed in User
in my app, I receive a deep link url "myapp://events/[event_id]"
(via sms, for example).
I want to join that Event
when I click the link and display the Event
's information on screen.
The process works like this:
- user clicks the link
- the app receives the url and extracts the
event_id
- with the
event_id
the app retrieves theEvent
's information - the app saves that information in local storage
- the app sends a POST request letting the server know that a new user (me) has joined the event
- the app displays the retrieved
Event
's information to the user
When the app sends the POST request to join the event, it sends the current_user
's id, which is handled by the backend (I'm using Parse with Facebook login). This means that all the user authentication is handled by Gateway
s (with Parse the current_user
's id comes in the form of PFUser
, but with some other implementation it could be a String
, so it must be handled by Gateway
's).
My question is, should this whole interaction (joining the Event
) be handled by a Gateway
or by an Interactor
?
- To me it seems more logical that the
Interactor
should handle all that process:
- retrieving information with the
event_id
- adding the
current_user
to theEvent
- calling the
Gateway
to save theEvent
locally)
But if it is handled by anInteractor
, it means that thisInteractor
will need knowledge aboutPFUser
(if I'm using Parse), and will have to change it's implementation if I stop using Parse (which I will).
- retrieving information with the
- If it is handled by a
Gateway
, it means that theInteractor
will just be forwarding thejoin
call to theGateway
(joinEventInteractor.join(eventId: String, callback: () -> ()) { eventGateway.join(eventId, callback: callback) }
).