How is layer between MVC controller and back-end called?

Question

I have ASP.NET MVC application with the following controller and action:

public class AccountsController
{
    public ActionResult Index() 
    {
        var accounts = _accountsManager.GetAccounts();
        return View(accounts);
    }
}

and AccountsManager class like this:

public class AccountsManager
{ 
    private ILogger Logger ...
    private ICache Cache ...
    private IAccountsService Service ...
    private IMapper ViewModelMapper ...

    private const string CacheKey = "Accounts";

    public AccountViewModel[] LoadAccounts() 
    {
        try 
        {
            if (Redis.TryGet(CacheKey, out var cached)) // Cache
                return cached;

             var accounts = Service.GetAccounts(); // Call service
             var vms = ViewModelMapper.Map<AccountViewModel[]>(accounts); // Map result

             Redis.Set(CacheKey, vms); // Update cache
             return vms;
        } 
        catch (Exception ex)
        {
            Logger.Error(ex); // Log exceptions
            throw;
        }
    }
}

So, this AccountsManager class removes code duplication and encapsulates the following logic:

• Communication with back-end
• Resolving dependencies
• Caching
• Logging
• Error handling
• ViewModel mapping
• Request retrying, service auth etc.

However, calling this classes XXXManager makes me feel uncomfortable since this word Manager is ambiguous.

How is this layer usually called?

Answer 1

Normally I would say 'Service Layer'

But it looks like your AccountManager is an extra layer between the Hosting and Service Layers.

I would question the logic of having this extra layer.

• Your service layer should return the same objects regardless of how it is accessed. You shouldn't need that AccountViewModel

• Is the caching part of the service or part of the hosting? If you are just caching the end result do it on the hosting layer and you wont hit the code at all.

• Logging, again I would either inject ILogger into the service or have it at the Hosting Layer to catch things like binding and routing errors

Answer 2

Using Martin Fowler's Patterns of Enterprise Application Architecture, terminology, this would be called a Gateway because it's the gate to the back-end system, and it encapsulates all the back-end interaction details. You could then see it as part of a data source layer, that decouples the M of MVC from the dirty details. If the back-end is a database, there are more specific pattern names depending on how exactly you access the database to work with the objects.

If you're fan of hexagonal architecture, you'd call this AccountManager an adapter. In the clean architecture it would be a gateway in the adapter layer.

---

Unrelated remark: when looking at all the responsibilities of that class, I just wonder if it's compliant with SRP.