CODEWITHSUNDEEP
c#sql-serverasp.net-mvcentity-framework
Flexabust Bergson
Flexabust Bergson

Reputation: 762

Have I understood architectural design with ASP.NET MVC and Entity Framework?

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

EFDal is EntityFramework Data Access Layer.

And from what I understood, Service layer would contain methods that call the DAL which in turn is used to access data.

Do you see something wrong in my approach?
Am I right in saying the Service Layer, is the one containing all operations? (eg: Searching a user in DB -> Service Layer launches search by calling EFDal which returns the value, and in turn Service Layer returns a ViewModel to the controller) (also see: Creating a Service Layer for my MVC application?)

Finally, Should my Service layer classes implement Interfaces for persistence purposes?

As a student we only used MVC pattern for our projects, and never had to expand the solution with new projects because we worked on small projects. Here I feel like misconceiving the architecture will end up in disastrous maintainability. Thanks for your help!

Upvotes: 2

Views: 706

Answers (1)

IvanJazz
IvanJazz

Reputation: 773

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 DTO.

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.

Benefits of DTO

  1. You are not directly exposing your domain entities, i.e your EntityFramework POCO classes. However, a case can be made for a project small enough to avoid DTO all together.
  2. In case in the future you decided to add an WebAPI function along your MVC project, say, for an iPhone application. The new application uses the WebAPI that also consumes the service layer, most of the service layer codes can be re-used since they return DTO classes and not ViewModel that is constructed for the View itself.

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.

Upvotes: 2

Related Questions