2

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?

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.

  • 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 Jan 27 '16 at 11:56
  • 1
    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?) – Lobsterpants Jan 27 '16 at 12:21
  • @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. – Alternatex Jan 27 '16 at 12:28
  • "Service" - of course! That makes so much more sense, brilliant thanks. – Lobsterpants Jan 27 '16 at 13:16

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.