è una cattiva pratica che il controller chiama il repository anziché il servizio?

è una cattiva pratica che il controller chiama il repository anziché il servizio?

per spiegare di più:

Ho scoperto che, in una buona progettazione, i controller chiamano il repository di servizio e servizio.

ma a volte nel controller non ho / ho bisogno di alcuna logica e devo solo recuperare da db e passarlo per visualizzarlo.

e posso farlo chiamando semplicemente il repository - non c'è bisogno di chiamare il servizio - è una cattiva pratica?

No, pensala in questo modo: un repository è un servizio (anche).

Se le entità recuperate tramite il repository gestiscono la maggior parte della logica aziendale, non sono necessari altri servizi. Basta avere il repository è sufficiente.

Anche se hai alcuni servizi che devi attraversare per manipolare le tue entità. Prendi prima l'entità dal repository e poi passala a detto servizio. Essere in grado di lanciare un HTTP 404 prima ancora di provare è molto conveniente.

Inoltre, per gli scenari di lettura è comune, è sufficiente che l'entità lo proietti su un DTO / ViewModel. Avere un livello di servizio intermedio spesso porta a molti metodi di passaggio che sono piuttosto brutti.

Non è una cattiva pratica per un controller chiamare direttamente un repository. Un "servizio" è solo un altro strumento, quindi usalo dove ha senso.

NikolaiDante ha commentato:

... Scegli il modello giusto per l'applicazione giusta. Quello che direi è che dovresti rendere coerente la tua candidatura.

Non credo che la coerenza sia l'aspetto più importante. Una classe di "servizio" è intesa per incapsulare una logica di livello superiore in modo che il controller non debba implementarla. Se non è richiesta una "logica di livello superiore" per una determinata operazione, basta andare direttamente al repository.

Per promuovere una buona separazione delle preoccupazioni e della testabilità, il repository dovrebbe essere una dipendenza che si inietta nel servizio tramite un costruttore:

IFooRepository repository = new FooRepository();
FooService service = new FooService(repository);

service.DoSomething(...);

Se la ricerca di record nel database richiede una sorta di query con parametri, una classe di servizio potrebbe essere un buon posto per accettare il modello di visualizzazione e creare una query che viene quindi eseguita dal repository.

Allo stesso modo, se si dispone di un modello di visualizzazione complesso per un modulo, una classe di servizio può incapsulare la logica di creazione, aggiornamento ed eliminazione dei record chiamando metodi sui modelli / entità di dominio, quindi persistendoli utilizzando un repository.

Andando nella direzione opposta, se il controller ha bisogno di ottenere un record dal suo ID, delegare a un oggetto di servizio per questo è come colpire una puntina da disegno con una mazza - è molto più del necessario.

Ho scoperto che il controller è nella posizione migliore per gestire la transazione o un oggetto Unit Of Work . Il controller o l'oggetto Unit Of Work delegherà quindi agli oggetti di servizio per operazioni complesse o andrà direttamente al repository per operazioni semplici (come trovare un record per ID).

public class ShoppingCartsController : Controller
{
    [HttpPost]
    public ActionResult Edit(int id, ShoppingCartForm model)
    {
        // Controller initiates a database session and transaction
        using (IStoreContext store = new StoreContext())
        {
            // Controller goes directly to a repository to find a record by Id
            ShoppingCart cart = store.ShoppingCarts.Find(id);

            // Controller creates the service, and passes the repository and/or
            // the current transaction
            ShoppingCartService service = new ShoppingCartService(store.ShoppingCarts);

            if (cart == null)
                return HttpNotFound();

            if (ModelState.IsValid)
            {
                // Controller delegates to a service object to manipulate the
                // Domain Model (ShoppingCart)
                service.UpdateShoppingCart(model, cart);

                // Controller decides to commit changes
                store.SaveChanges();

                return RedirectToAction("Index", "Home");
            }
            else
            {
                return View(model);
            }
        }
    }
}

Penso che un mix di servizi e lavorare direttamente con i repository sia perfettamente accettabile. Potresti incapsulare ulteriormente la transazione in un oggetto Unit Of Work se ne sentissi la necessità.

La ripartizione delle responsabilità è la seguente:

• Il controller controlla il flusso dell'applicazione
  • Restituisce "404 non trovato" se il carrello non è presente nel database
  • Riesegue il rendering del modulo con messaggi di convalida se la convalida non riesce
  • Salva il carrello se tutto viene estratto
• Il controller delega a una classe di servizio per eseguire la logica aziendale sui modelli di dominio (o entità). Gli oggetti di servizio non devono implementare la logica aziendale! Essi eseguono la logica di business.
• I controllori possono delegare direttamente ai repository per operazioni semplici
• Gli oggetti di servizio accettano i dati nel modello di vista e delegano a Modelli di dominio per eseguire la logica aziendale (ad es. L'oggetto di servizio chiama i metodi sui Modelli di dominio prima di chiamare i metodi nel repository)
• Gli oggetti del servizio delegati ai repository per la persistenza dei dati
• I controller dovrebbero:
  1. Gestire la durata di una transazione, o
  2. Creare un oggetto Unit Of Work per gestire la durata di una transazione

Dipende dalla tua architettura. Uso Spring e la transazionalità è sempre gestita dai servizi.

Se chiamate repository direttamente per operazioni di scrittura (o semplici servizi senza logica che semplicemente delegano al repository), probabilmente state utilizzando diverse transazioni di database per un'operazione che deve essere eseguita in una sola. Ciò porterà a dati incoerenti nel database. Come regola generale, le operazioni del database dovrebbero funzionare o dovrebbero fallire, ma le operazioni a metà lavoro sono la causa del mal di testa.

Per questa ragione penso che chiamare i repository direttamente dai controller o usare semplici servizi di delega sia una cattiva pratica. Inizi a farlo solo per leggere, e molto presto tu, o uno o i tuoi compagni inizierete a farlo per le operazioni di scrittura.