MVC design pattern, service layer purpose?

TL;DR

1. See explanation below
2. Layers above Service Layer should not be "aware" that more Layers exist below the Service Layer.
3. Not necessarily, because you can have for example Data from 1 Type scattered across 2 tables and the "Core" only see's one, the Data Access Layer is responsible for "Grouping" and returning the Service Layer Type

Explanation

The typical 3-layer architecture is composed of Presentation Layer, Service/Domain Layer, Data Access Layer (DAL).

Think of the Service layer as the "Core" of your Application. Typically, the Service Layer only has Repository Interfaces that will be implemented in the DAL.

Therefore it allows you to "easily" switch the way you access data. The objects returned by the service layer should not be DAO's, because after all, the Presentation Layer doesn't even "know" the DAL exists.

Scenario: You have a 3-tiered Solution. Currently doesn't make much sense in having all layers.

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

Now you want to have a REST API in ASP.NET MVC WebApi

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

Now, for example, you no longer want to use Entity Framework as your Data Access and want to use NHibernate.

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

Notice that we added a new form of Presentation and switched the way we access Data, but the Service Layer never changed.

Typically, the Service Layer exposes Interfaces to be implemented in the Data Access Layer so we get the "abstraction" we want.

I implemented a project with this architecture in university. You can check out the code HERE

I hope this helped. Sorry if I'm so boring @ explaining things :P

Ad.1 Service layer should be place for whole business logic. It's more about separate responsibilities:

• Controller - responsible for prepare viewModel and pass to the specific view,

• Repository - abstract layer responsible for gathering entities from DB

• Service - responsible for complex logic. There is often case that service uses many entities to make some logic and return just DTO.

Ad.2 In my opinion service layer should return DTO objects which should be mapped to the viewModels in Controllers.

Ad.3 No this is not the case. In your example you can move GetBadCust and GetGoodCust from repo to the service and return some DTO