N-Tier Architecture with MVC4 EF and Repository Pattern

asp.net-mvc-4 design-patterns entity-framework-6 n-tier-architecture repository-pattern


I'm using MVC and EF to build an example web application with various layers. Additionally, I use the Repository Pattern to access databases. I just

There are layers.

  1. University Business

    • calls to the repository and business logic operations.
  2. student data

    • Object POCO
    • Object Context
    • Repository of Entities
  3. Student Materials

    • include domain objects
  4. Web App MVC
    • Controllers of Entities (after instantiating Services here)
    • I'm binding all the interfaces with NInject (this project contains references to all other layers).

I need advice on this design's advantages and disadvantages.

9/27/2014 6:02:00 AM

Accepted Answer

I'll address a few points based on my recent experience with similar architecture in addition to the adv. and disadv. (http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips#nAdvantages) that are defined for N-tier:

Benefits include

  • You can share the Service Project for various purposes, such as Windows Desktop, because controllers are thinly layered and business logic is kept in actual services. In the future, you can also expose the same service for Webapi. Reusability is high as a result.

    • Each Layer is performing a specific, assigned task, and NInject makes it simple to swap out those tasks. I have a fantastic example in my current project where I use the mail gateway provided by Exchange Online services in debug mode. As a mail gateway, though, I must use SMTP services for Release. (Check out the DI advance drawbacks individually.)
  • You can use Mocks for TDD as long as you follow the Interfaces for NInject. Therefore, you can include the benefits of TDD and DI in your list.

  • Code First is a wonderful way to represent your database because it is clear and open. You are aware of the situation.

  • The key selling point is database version management with Code first.


  • You cannot deploy these components independently even though you are conceptually separating them. Scaling is therefore possible with adequate session management. thus, more labor.

  • There are too many CS files, one for each Controller (or two), Service (or classes), and Repository (1 Interface, 1 Class). Therefore, it will rise considerably depending on your application. I already need to manage more than 100 files. However, you can eliminate this handicap and turn it into your own advantages with the aid of Resharper.

  • Although you may create generic CRUD actions for a controller, repository, and services. There will come a moment when you'll decide to create separate services for each controller, among other things.

    • Although I believe it has been a case for any N-tier, I find that Validation will be present everywhere.
  • If you use POCO with code first, you must understand migration extremely well; I am still having trouble finding many solutions.

  • For Code first DbContext, there isn't a direct or simple way to invoke functions (as you do with import functions, sp in Database first - edmx). Although it is clean, numerous hacks can be necessary.

  • Since Code initially constructs the database for you, database administration does not necessitate version control. However, I find dealing with deploying, views, functions, and sp; code necessary, complicated.

  • I suppose how you write your code will have an impact on performance.

Overall, I am quite satisfied with the architecture I am using for my Webapi and I am strictly adhering to it.

9/27/2014 6:32:59 AM

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow