Lo scopo di un livello di servizio è quello di fornire un livello di astrazione tra il livello di persistenza (operazioni CRUD) e il livello di presentazione.
Dato questo, non sorprende che stai trovando libri che dicono che non è una buona idea per il tuo livello di presentazione interagire direttamente con gli oggetti del tuo repository. L'intero punto del livello di servizio è quello di proteggerti dal dover interagire direttamente con il database; farlo ignorerebbe l'astrazione che cerchi.
Se stai fornendo un Service Layer tra il tuo client (il livello di presentazione) e il tuo database (cioè il repository), dovresti esporre i metodi nel tuo Service Layer che forniscono servizi , non CRUD operazioni. In effetti, puoi pensare al tuo livello di servizio come traduttore tra le operazioni CRUD e le pratiche commerciali.
Ad esempio, il tuo livello di servizio potrebbe esporre un metodo chiamato CreateInvoice() . Per fare ciò, questo metodo di servizio dovrebbe cercare Customer , Invoice Header , Invoice Line Item , Product e Pricing entità dal tuo repository. Fa tutto questo tramite operazioni CRUD. Ma non otterrai tutte queste entità come valore di ritorno; piuttosto, hai maggiori probabilità di ottenere una sorta di oggetto composito ViewModel che contenga una vista di tutti i dati richiesti per il rendering della fattura.
Quindi no, non passeresti semplicemente le tue chiamate CRUD all'API del Service Layer. Farlo è davvero ridondante e vanificherebbe l'intero scopo di avere un livello di servizio.
Ulteriori letture
P del catalogo EAA | Service Layer