How to architect MVC 3, EF, ViewModels, AutoMapper, POCO, Repository and Unit of Work in n-tiered project?

Question

I have been reading countless articles about how to architect a new MVC 3 application using best practices.

90% of the articles combine the EF EDMX files into the same project as the MVC app. Those that do seperate these items into their own projects don't clarify which project each goes into and what references each project has. Usually they consist of code snippets that are great to teach how to do a specific function, but don't tell me how to architect the solution.

I believe that I need at least 5 projects in my solution. Can anyone tell me if I have the correct layout here?

• Data Access Layer - Contains the EF EDMX files. (Perhaps the DBContext auto-generated code?)
• Business Layer - Contains the IRepository and Repository classes, UoW classes, as well as the business logic for the domain. - Contains reference to DAL.
• ViewModels - Contains the viewmodels that will use AutoMapper to go between my DAL and the presentation layer. - Contains reference to DAL.
• MVC 3 App - Standard MVC 3 app. Contains references to the BusinessLayer and the ViewModels projects.
• Test - Unit testing.

Does this look right? Can anyone point me to a good article that uses n-tiered development with ViewModels, AutoMapper, Repository patterns and EF4?

Answer 1

When looking at what project to put something in, it helps to think about how you are going to be deploying your code. Put code that will ship together in the same project and then use namespaces to separate it out logically into separate tiers. For most of the projects I work on it tends to be pretty simple with 3 projects.

Business Layer

• Domain/Business Model and Services
• Data Access Layer

MVC App

• View Models
• Automapper
• Controllers
• Views

Tests

• Unit tests

Answer 2

I like the following

Domain - contains models and ViewModels

Services -business logic and viewmodel hydrating (ie population) code

Contracts or interfaces - repository interfaces, unit of work, IContext, and ICache Web site DataAccess - concrete implementation of entity framework

Some include their AutoMap code directly as an action filter as an attribute inside the web project. My automap code is done in the services project (but again this is up to you) unless I can use the attribute to do it in the controller.

btw see Jimmy's nice attribute here: http://lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models/

What you have outlined above is fine as well though. This is a very subjective matter. My general recommendations are that 'if someone can open a project and have an idea where to look for something, you are likely doing it correctly'

Answer 3

The way I usually do it:

1. Model project - Contains the model generated from the db and the context.
2. POCOs project - Contains the Business entities
3. Controller project - similar to your repository
4. MVC3 project - front end, INCLUDING view models and repository classes that include automapper equivalencies.
5. Unit tests

Architecture is technology independant, whether you are using EF, Hibernate, MVC, webforms etc... And you usually combine patterns. Besides is mostly depends on each particular project.

Regarding to best practices, when talking about EF, I can't link you to the source I use because I use a book. However I'll link you to the author's blog, it's Julie Lerman's Programming Entity Framework.