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?

• Neil: 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.
• kayess: 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).
• MetaFight: @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.
• kayess: @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.
• MetaFight: @kayess we appear to think alike.

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.

• Robert Harvey: Quite a testament to the alphabet soup that is our professional vocabulary
• Christophe: @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...