MVC design pattern, service layer purpose?

Question

Let's say I have a following repo pattern :

interface IGenericRepo<T> where T : class
{
     IEnumerable<T> GetAll();
     T GetById(object id);
     void Insert(T obj);
     void Update(T obj);
     void Delete(T obj);
     void Save();
}

interface ICustRepo : IGenericRepo<Cust>
{
     IEnumerable<Cust> GetBadCust();
     IEnumerable<Cust> GetGoodCust();
}

public class CustRepo : ICustRepo<Cust>
{
     //implement method here
}

then in my controller :

public class CustController
{
     private ICustRepo _custRepo;

     public CustController(ICustRepo custRepo)
     {
         _custRepo = custRepo;
     }

     public ActionResult Index()
     {
         var model = _custRepo.GetAll();
         return View(model);
     }

     public ActionResult BadCust()
     {
         var model = _custRepo.GetBadCust();
         return View(model); 
     }
}

Basically my pattern is something like

View <-> Controller -> Repo -> EF -> SQL Server

but I saw a lot of people doing this

View <-> Controller -> Service -> Repo -> EF -> SQL Server

So my question is :

1. Why and when do I need service layer? Isn't that just add another unnecessary layer because every non-generic method is already implemented in ICustRepo?

2. Should the service layer return DTO or my ViewModel?

3. Should the service layer map 1:1 with my repo?

I've look around for few days but I haven't satisfied with the answers.

Any help will be appreciated and apologize for bad english.

Thank you.

UPDATE :

Difference between Repository and Service Layer?

I've already read this. I already know the difference between those 2, but I wanna know why and the purpose. So that doesn't answer my question

Answer 1

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

Answer 2

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