ASP.NET MVC Middle tier object naming

Question

As a corporate developer who works alone I find myself creating and writing a lot of websites that consist of screens that are basically wrappers for a DB table. So for instance on a screen that updates companies I would have a controller like this:

 public class CompaniesController
{
 private readonly ICompaniesManager manager;
 public CompaniesController(ICompaniesManager manager)
 {
 this.manager = manager;
 }
 [HttpPost]
 public JsonResult Update(Company company)
 {
 // validation goes here
 this.manager.Update(company);
 // handle update result
 }
}

this controller is talking to a middle tier "Manager" class.

 public class CompaniesManager : ICompaniesManager
{
 private readonly ICompaniesRepository repository;
 public CompaniesManager(ICompaniesRepository repository) 
 {
 this.repository = repository;
 }
 public void Update(Company company)
 { 
 // business logic & caching code 
 this.repository.Update(company);
 }
}

As you can see this is talking to a repository class that actually handles updating the database.

So I always seem to end up with the pattern xxxController -> xxxManager -> xxxRepository (where xxx is the object/table). I keep finding myself wondering if I am missing something fundamental about how a 3 tier app should work or how middle tier classes should be named.

Would this be considered a correct 3-tier architecture or am I missing something?

Answer 1

What you have there seems like a standard architectural solution for MVC applications. Since MVC does not provide a solution for the data layer you have a repository. So the 3-layers are:

• Business layer: where your classes appended by "Manager" are
• Data layer: repository
• Presentation layer: View and Controller

EDIT:

You should change the word "Manager" to "Service" since what you have there is called a service layer. We usually append the word "Manager" (or "Helper", or "Util") to static classes - something which may be a code smell.

• Lobsterpants: Thanks for the feedback, interesting stuff. Like the idea of using "Model" instead of "Manager" if only to prevent the confusion that a StaffManager class causes!
• Lobsterpants: Hmmm " what you call CompaniesManager I would call Company." -> But the datastructure I am using is called Company. Can't help feeling that would get confusing (and wouldnt compile?)
• Alternatex: @Lobsterpants Oh sorry, I got a bit confused :) Instead of CompaniesManager I would call it CompaniesService which implements ICompaniesService since what you have there is called a service layer. So just replace "Manager" with "Service". The word "Manager" is not right here because it's synonymous with "Helper" or "Util" which are words we usually append to static/helper classes.
• Lobsterpants: "Service" - of course! That makes so much more sense, brilliant thanks.