The answer to this question is to some degree both subjective and opinion-based. That being said..
It is fine for HomeController
to call Product
and Client
related methods to return what will effectively become your HomeIndexViewModel
(which would comprise of some kind of ProductViewModel
and ClientViewModel
properties - your view would access the data via Model.ProductViewModel
, Model.ClientViewModel
, etc).
I would go a step further and add an orchestration component, which will be responsible for handling the request and application logic required by the Index
action of your HomeController
. This should keep your controller thin and decoupled from the backend.
public class HomeController : Controller
{
private readonly IOrchestrator orchestrator;
public HomeController() : this(IOrchestrator orchestrator)
{
}
public HomeController(IOrchestrator orchestrator)
{
this.orchestrator = orchestrator;
}
public async Task<ActionResult> Index()
{
var homeIndexViewModel = await orchestrator.GetHomeProductsAndClientsAsync();
return View(homeIndexViewModel);
}
}
GetHomeProductsAndClientsAsync()
will obviously be a method of your FooOrchestrator
class that will be handling the application logic to return a HomeIndexViewModel
.
The orchestrator is passed in to HomeController
as an interface (IOrchestrator
, rather than the FooOrchestrator
class which will implement the IOrchestrator
interface) to facilitate dependency injection (though, IMHO, the approach is still beneficial without DI).
Some reading:
"Never Mind the Controller, Here is the Orchestrator" (Dino Esposito)