4

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?

  • 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 '17 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 '17 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 '17 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 '17 at 10:36
  • 2
    @kayess we appear to think alike. – MetaFight Nov 17 '17 at 10:38
3

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

1

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 – Robert Harvey Nov 18 '17 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 '17 at 10:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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