Motivo di progettazione MVC, scopo del livello di servizio?

Question

Diciamo che ho un modello seguente repo:

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 
} 

poi nel mio 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); 
    } 
} 

Fondamentalmente il mio modello è qualcosa di simile a

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

ma ho visto un sacco di persone che lo fanno

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

Quindi la mia domanda è:

1. Perché e quando ho bisogno service layer? Non è che aggiungere un altro livello non necessario perché ogni metodo non generico è già implementato in ICustRepo?

2. Se il livello di servizio restituisce DTO o il mio ViewModel?

3. Il livello di servizio deve mappare 1: 1 con il mio repository?

Ho guardato in giro per qualche giorno ma non sono soddisfatto delle risposte.

Qualsiasi aiuto sarà apprezzato e si scuserà per il cattivo inglese.

Grazie.

UPDATE:

Difference between Repository and Service Layer?

ho già letto questo. Conosco già la differenza tra questi 2, ma voglio sapere perché e lo scopo. In modo che non risponda alla mia domanda

Answer 1

TL; DR

1. Vedi spiegazione al di sotto
2. Livelli superiori di livello di servizio non dovrebbe essere "consapevole" che più livelli esistono sotto il livello di servizio.
3. Non necessariamente, perché si può avere per esempio dati da 1 Tipo sparsi per 2 tavoli e il "Core" solo di un vedere, il Data Access Layer è responsabile di "raggruppamento" e il ritorno il tipo di servizio di livello

Spiegazione

L'architettura tipica a 3 livelli è composta da Presentation Layer, Service/Domain Layer, Data Access Layer (DAL).

Pensa al livello di servizio come il "nucleo" della tua applicazione. Tipicamente, Service Layer ha solo interfacce del repository che verranno implementate nel DAL.

Pertanto, consente di "facilmente" cambiare il modo in cui si accede ai dati. Gli oggetti restituiti dal livello di servizio non dovrebbero essere DAO, perché dopo tutto, il livello di presentazione non "sa" nemmeno il DAL esistente.

Scenario: Si dispone di una soluzione a 3 livelli. Attualmente non ha molto senso avere tutti gli strati.

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

Ora si vuole avere un API REST in ASP.NET MVC WebAPI

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

Ora, per esempio, si desidera più utilizzare Entity Framework come accesso ai dati e si vuole usare NHibernate.

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

noti che abbiamo aggiunto una nuova forma di presentazione e cambiato il nostro modo di accedere ai dati, ma il livello di servizio mai cambiato.

Tipicamente Service Layer espone le interfacce da implementare nel livello di accesso ai dati in modo da ottenere "l'astrazione" che vogliamo.

Ho implementato un progetto con questa architettura all'università. È possibile controllare il codice HERE

Spero che questo ha aiutato. Scusa se sono così noioso @ che spiega le cose: P

Answer 2

Ad.1 Livello di servizio dovrebbe essere posto per tutta la logica di business. E 'più di responsabilità distinte:

• Controller - responsabile per preparare ViewModel e passare alla vista specifica,

• Repository - strato astratto responsabile per la raccolta di entità da DB

• servizio - responsabile logica complessa. C'è spesso il caso che il servizio utilizzi molte entità per fare qualche logica e restituire solo DTO.

Ad.2 A mio parere livello di servizio deve restituire gli oggetti DTO che dovrebbe essere mappati ai ViewModel nel controller.

Ad.3 No, questo non è il caso.Nel tuo esempio è possibile spostare GetBadCust e GetGoodCust da pronti contro termine al servizio e tornare un po 'DTO