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() 
            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

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?

  • I've never heard of a term for such a role, but if I had to given it a name, I'd call it a service layer. In other words, it's the part that deals with error handling and in general, the first place you'd check to verify that everything is working as it should.
    – Neil
    Nov 17, 2017 at 7:34
  • Probably you search for the term called Application Service which might act as composer of use cases, might be an API for the UI layer(s).
    – kayess
    Nov 17, 2017 at 7:55
  • @kayess you beat me to it :) I have found myself calling it the Application Service Layer in the past. I don't know how common that is, though.
    – MetaFight
    Nov 17, 2017 at 10:34
  • @MetaFight good! Really common in the software dev. vocabulary. Upper layer is Application service which is a composer of every nuts and bolts you need to use for the given use-case or command/task/whatever. It can call further Domain services, send queries, send commands to aggregates, manage the unit of work, etc.
    – kayess
    Nov 17, 2017 at 10:36
  • 2
    @kayess we appear to think alike.
    – MetaFight
    Nov 17, 2017 at 10:38

2 Answers 2


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


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.

  • Quite a testament to the alphabet soup that is our professional vocabulary Nov 18, 2017 at 2:44
  • @RobertHarvey :-) indeed. With a dozen of naming conventions on the layers, using each subtle differences to justify their existence, there is definitely no universal truth. We could also debate about the hijacking of the term MVC for an architecture using ViewModels ;-) Nevertheless I like these terminology questions, because it forces to think about the real purpose and intent of the objects, which is the first step to clear responsibilities, which are the common denominator behind all the architectures...
    – Christophe
    Nov 18, 2017 at 10:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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