In a three tier model (UI, Service, Repository projects with separate interface and data model projects) I understand the idea of passing in an instance of the Repository to the Service layer and having the Service layer code to an external interface. This works well with one to one relationship between the Service object and the Repository object.
My question however is: If we abstract the business logic into the service layer and make a single call to the service layer to get data (of a list thereof), how do we handle a situation where a single call makes calls out to two (or more) endpoints?
The idea of abstraction should hide this implementation detail from the UI layer but what if inside the Service layer we make a call to a webAPI to get user information and then make a database call to get history for them as part of the return object? Conceptually this relates to getting user info and should be one call from the UI layer but I wouldn't typically mix a web call and a database call in the Repository layer. I would usually have them separate since the only reason they are related is through the business rules and either or both could be used or swapped independently and then called individually from the Service layer. It seems odd to think that I would have to try to pass two objects in the Service layer's constructor. The only other thing I can think of is to make the UI make two distinct calls into the Service layer to assemble the fully fleshed out model and that seems to be putting business logic in the UI.
Thank you for the guidance.
Aucun commentaire:
Enregistrer un commentaire