2

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!

Flexabust Bergson
  • 677
  • 9
  • 30
  • There are many possible architectures depending on the application size. For smaller apps you might get by with a single MVC project that references EF. Most of ours are medium sized where we create App.Data for the EF stuff (context, fluent, migrations) App.Entities for our POCO models and App.MVC for our UI and then use Automapper to create our ViewModels. [CQRS](https://msdn.microsoft.com/en-us/magazine/mt147237.aspx) is another option. – Steve Greene Jun 12 '17 at 13:57
  • @SteveGreene Thank you for your answer. That's kind of what I'm going for. Never used Automapper though and not sure I need it, all my DB tables are quite simple, I just have a lot of them. At least from what I've understood Automapper is used for complex objects ? I can't really say how big the application is, but there are 4.5k employees in the company (and an intern doing this kind of stuff ...) and many different operations to manage through Active Directory or SQL Server, so I need good performance. – Flexabust Bergson Jun 12 '17 at 14:15
  • 1
    Performance and architecture will often be trade offs. EF is not the most performant data access technology. See [here](https://stackoverflow.com/questions/8347670/entity-framework-is-too-slow-what-are-my-options). It's one of the reasons SO went with Dapper. – Steve Greene Jun 12 '17 at 15:56
  • @SteveGreene Interesting post, though they do say that optimizing EF requests does make for better performance. But I do need a performant Data Access since one of the basis of the project is making it faster than the one already in production. I'll check out Dapper to see wich one is most fit to my needs thanks! – Flexabust Bergson Jun 13 '17 at 07:36
  • EF is sufficiently performant for even our biggest app, but Stack Overflow type volume is another thing. – Steve Greene Jun 13 '17 at 13:18
  • @SteveGreene Hah yeah. Alright, seems like the option to go for and also has a lot of good documentation and good user experience. Anyways if I do the right architecture it can always be changed in time. – Flexabust Bergson Jun 13 '17 at 13:22

1 Answers1

2

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.

IvanJazz
  • 683
  • 1
  • 6
  • 17
  • 1
    the Onion link is broken – Andrei Jun 12 '17 at 13:58
  • @IvanJazz Ok thanks! I will read these articles right away(and Mosh's video, always on point!). So the ViewModel POCOs will create instances of the Service Layer classes right? And inside the Service Layer I have a class and its corresponding interface? – Flexabust Bergson Jun 12 '17 at 14:06
  • 1
    @Flexabustbergson The `ViewModel POCOs` are constructed by the controller of your MVC application, by calling various services from your service layer. If you intend to truly decouple your application from its services, then yes, having interfaces for each services is desirable as it helps in unit-testing and mocking. – IvanJazz Jun 12 '17 at 14:13
  • @IvanJazz There is one thing I do not understand in the onion archirecture article you posted: In the first folder 01-Domain is where all my DB POCOs will go? should I add a new project for each DB? And if I have other Business logic I should put it there with an interface for each class? – Flexabust Bergson Jun 13 '17 at 09:20
  • 1
    @Flexabustbergson Yes, your DB POCO lives in Domain.Entities. Business logic is part of your service layer which is in the project Services. You don't have to follow exactly what the article does though, the main takeaway is the dependency of each project, i.e the correct references you add to each project. – IvanJazz Jun 13 '17 at 10:54
  • @IvanJazz Alright nice. well It does seem pretty close except for the Domain.Interfaces which won't be needed for POCOs (but would be good for business logic). So thanks again for this ressource because it's not easy to find architecture examples out there (or they are all different and don't seem as efficient as this one). – Flexabust Bergson Jun 13 '17 at 11:00