MVC design pattern, service layer purpose?

asp.net-mvc c# design-patterns entity-framework repository

Accepted Answer

TL;DR

  1. See clarification below.
  2. Layers above the service layer shouldn't "know" that there are more layers below the service layer.
  3. Not necessary, since the Data Access Layer is in charge of "Grouping" and returning the Service Layer Type, even if, for instance, Data from One Type is Dispersed Across Two Tables and the "Core" Only Sees One.

Explanation

The Presentation Layer, Service/Domain Layer, and Data Access Layer make up the standard 3-layer architecture (DAL).

Consider the service layer to be your application's "Core." Typically, the DAL will simply implement the Service Layer's Repository Interfaces.

As a result, you can "simply" change how you access data. Since the Presentation Layer doesn't even "know" that the DAL exists, the objects returned by the service layer shouldn't be DAOs.

You have a three-tiered solution, as an example. Presently, having all levels makes little sense.

      /-------------------\
      |      Web App      | <--- Presentation Layer
      |-------------------|
      |  Service Library  | <--- Service Layer
      |-------------------|
      | Entity Framework  | <--- Data Access
      \-------------------/

You now desire an ASP.NET MVC WebApi REST API.

      /--------------------\
      | Web App | REST API | <--- Presentation Layer
      |--------------------|
      |  Service Library   | <--- Service Layer
      |--------------------|
      |  Entity Framework  | <--- Data Access
      \--------------------/

For instance, you might now prefer to utilize NHibernate as your data access method instead of Entity Framework.

      /--------------------\
      | Web App | REST API | <--- Presentation Layer
      |--------------------|
      |  Service Library   | <--- Service Layer
      |--------------------|
      |     NHibernate     | <--- Data Access
      \--------------------/

You'll see that while we altered how we access Data and added a new type of Presentation, the Service Layer remained constant.

In order to achieve the desired "abstraction," the service layer typically offers interfaces that the data access layer can implement.

In college, I used this architecture for a project. You can look up the code by typing HERE.

I hope that was useful. I apologize if this explanation is tedious:P

22
7/2/2015 10:42:28 AM

Popular Answer

Ad.1 The entire business logic should be at the service layer. The focus is largely on distinct responsibilities:

  • Controllers are in charge of creating viewModels and passing them to certain views.

  • Repository is an abstract layer in charge of collecting DB entities.

  • Service: in charge of intricate logic. It happens frequently that a service will use several entities to implement some logic and return merely a DTO.

Ad.2 In my perspective, the viewModels in the controllers should be mapped to the DTO objects that the service layer should return.

Ad.3 No, this is incorrect. You can transfer GetBadCust and GetGoodCust from the repository to the service and return some DTO in your example.



Related Questions





Related

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