3

I was going through some articles related to Futures and Callables today and was thinking about the best practices when working in an MVC based environment.

I was wondering, should one be creating Future objects in Controllers and force service classes to return a Future object.
I have a case when one particular API needs to get data from two different services and doing with Futures in Controllers will not block the second (or third...) call to another third party service. This seems the right idea and a sensible choice.

But this looks messy, On thinking a bit more, I thought creating a common service and hiding all the future object creation and third-party API calls seems good. As this makes everything non-blocking and Controllers do not feel like they are services.

Which path should we follow?

1

Just because you have controllers doesnt mean you cant have other objects as well.

Wrap your api in a client object and hide the messy implementation details there

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.