Search code examples
asp.net-mvc-4design-patternsrepository-patternentity-framework-6n-tier-architecture

N-Tier Architecture with MVC4 EF and Repository Pattern

I am creating sample web app with MVC and EF with multiple layers. I am also using Repository Pattern for database access. I just

The layers are

  1. Student Business

    • Calls to repository and performs business logics.

  2. Student Data

    • Entity POCO
    • Entity Context
    • Entity Repository

  3. Student Objects

    • contain domain objects
  4. MVC Web App
    • Entity Controllers (after instantiating Services here)
    • using NInject am binding all the interfaces(this project contains references to all other layers).

I need help over this design for its pros and cons.

Solution

  • In addition to the adv. and disadv. (http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips#nAdvantages) are defined for N-tier I will cover few points based on my recent experience with similar architecture:

    Benefits are:

    • Since controllers are thin layered and Business Logics are stored in Actual Services, you can share the Service Project for different purpose such as Windows Desktop etc.. You can also expose the same service for Webapi in the future. Hence re usability is high.

      • Each Layer is doing its own dedicated job and with the help of NInject you could easily swap the same. I have a great example in my current project where for debug mode I use Exchange Online services for mail gateway. Whereas for Release I have to use SMTP services as mail gateway. (Please check DI adv. drawbacks separately).

    • As you are following Interfaces for NInject, you can use Mocks for TDD. Hence You can add TDD and DI benefits in your list.

    • Code First is nice approach to represent your database, it is clean and transparent approach. You know what is happening.

    • Database Version control through Code first is the biggest selling point.

    Drawbacks:

    • Even though you are logically separating these components, but you cannot deploy these components separately. Hence scaling can be achieved through proper session handling. Hence more work.

    • Too many CS files, one for each Controller (1 or 2), Services ( 1 Interface and 1 Class), Repository (1 Interface, 1 Class). Hence depending on your application it will grow extensively. I already have more than 100 files to manage. But with the help of Resharper you can get rid of this drawback and convert that into your own benefits.

    • Even though you may write Generic CRUD operations for Repository, Controller as well as Services. There will be a time that you will end up going to the path of making each controller to have its own services and so forth...

      • I find that Validation will be everywhere, but I think it has been a case for any N-tier.

    • If you use POCO with Code first then definitely you need to understand Migration very well; I am still struggling to find many answers.

    • There is no direct and easy way to call functions (like you do import functions, sp in Database first - edmx) for Code first DbContext. It is clean but there are lots of hack that may require.

    • Like Code first creates the database for you hence there is no version control is required for database management. However, I find complex to deal with deploying, views, functions, sp; coding required.

    • In terms of performance, I guess that will come down to how you write code.

    Overall I am following exactly the same architecture for my Webapi and I am quite happy with this architecture.