I am currently working on an intranet website that uses Active Directory and SQL Server 2008. I have chosen ASP.NET's MVC design pattern and am now trying to figure out how to get a proper architecture for my project concerning the Data Access part using Entity Framework. I have been struggling for days in order not to go in the wrong direction (knowing that I'm the only developer in my company, it's my first experience and nobody knows about recent Frameworks). I have read about architecture and how to do it right, but I am not sure I grasped everything correctly (How do architect an ASP.Net MVC app with EF?).
Here is what I was thinking of doing, each layer having their own project (pardon my drawing skills):
Controller(MVC Project) ---uses---> Service Layer (Project) ---uses--> EFDal (Project)
^ | ^ |
| | | |
|<-------<-----returns ViewModel |<---------<------returns Query Result
You're almost in the right direction. However, the
ViewModel in this case should reside in the application layer, i.e. your
MVC layer. The service layer should in turn return a data transfer object, more commonly known as the
Think of the
ViewModel as a simple
POCO class that is built for the
View, it can be a collection of various
DTO returned by various services from your service layer.
POCOclasses. However, a case can be made for a project small enough to avoid
WebAPIfunction along your
MVCproject, say, for an iPhone application. The new application uses the
WebAPIthat also consumes the service layer, most of the service layer codes can be re-used since they return
DTOclasses and not
ViewModelthat is constructed for the
For your Data Access layer, no one explains better than this guy. Entity FrameWork With Repository Pattern
As for project structure, I would suggest an onion architecture. Onion Architecture. If you can understand this article well enough, you should be all set.