ASP.NET MVC - La logica di business dovrebbe esistere nei controller?

Derik Whitaker ha pubblicato un paio di giorni fa un articolo che ha colpito un punto che mi incuriosiva da tempo: la logica di business dovrebbe esistere nei controller?

Finora tutte le demo di ASP.NET MVC che ho visto hanno inserito l'accesso al repository e la logica di business nel controller. Alcuni addirittura inseriscono la convalida anche lì. Ciò si traduce in controller abbastanza grandi e gonfiati. È davvero questo il modo di utilizzare il framework MVC? Sembra che questo finirà con un sacco di codice e logica duplicati distribuiti su diversi controller.

La logica aziendale dovrebbe davvero essere nel modello. Dovresti mirare a modelli grassi, controller magri.

Ad esempio, invece di avere:

public interface IOrderService{
    int CalculateTotal(Order order);
}

Preferirei:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

Ciò presuppone che l'imposta venga calcolata da un servizio esterno e richiede che il modello conosca le interfacce dei servizi esterni.

Questo renderebbe il tuo controller simile a:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

O qualcosa di simile.

Mi piace il diagramma presentato da Microsoft Patterns & Practices . E credo nell'adagio "Un'immagine vale più di mille parole".

Questa è una domanda affascinante.

Penso che sia interessante che un gran numero di applicazioni MVC di esempio non riescano effettivamente a seguire il paradigma MVC nel senso di collocare veramente la "logica di business" interamente nel modello. Martin Fowler ha sottolineato che MVC non è uno schema nel senso della Gang Of Four. Piuttosto, è paradigma che il programmatore deve aggiungere modelli di se che stanno creando qualcosa al di là di un app giocattolo.

Quindi, la risposta breve è che la "logica di business" in effetti non dovrebbe risiedere nel controller, poiché il controller ha la funzione aggiuntiva di gestire la vista e le interazioni dell'utente e noi vogliamo creare oggetti con un solo scopo.

Una risposta più lunga è che è necessario riflettere sulla progettazione del livello del modello prima di spostare semplicemente la logica dal controller al modello. Forse puoi gestire tutta la logica dell'app usando REST, nel qual caso il design del modello dovrebbe essere abbastanza chiaro. In caso contrario, dovresti sapere quale approccio utilizzerai per evitare che il tuo modello si gonfi.

Puoi controllare questo fantastico tutorial di Stephen Walther che mostra la convalida con un livello di servizio .

Scopri come spostare la logica di convalida fuori dalle azioni del controller e in un livello di servizio separato. In questo tutorial, Stephen Walther spiega come è possibile mantenere una netta separazione delle preoccupazioni isolando il livello di servizio dal livello del controller.

La logica aziendale non deve essere contenuta nei controller. I controller dovrebbero essere il più magri possibile, idealmente seguire il picchiettio:

1. Trova entità di dominio
2. Agisci sull'entità di dominio
3. Preparare i dati per visualizzare / restituire i risultati

Inoltre, i controller possono contenere una certa logica dell'applicazione.

Allora dove metto la mia logica aziendale? Nel modello.

Cos'è il modello? Questa è una bella domanda. Consulta l' articolo Microsoft Patterns and Practices (complimenti ad AlejandroR per l'eccellente ricerca). Qui ci sono tre categorie di modelli:

• Modello di visualizzazione : si tratta semplicemente di un contenitore di dati, con una logica minima, se del caso, per passare i dati da e alle visualizzazioni, contiene la convalida dei campi di base.
• Modello di dominio : modello grasso con logica di business, opera su una o più entità di dati (ovvero entità A in un determinato stato rispetto all'azione sull'entità B)
• Modello di dati : modello compatibile con l' archiviazione, la logica contenuta in una singola entità si riferisce solo a quell'entità (cioè se il campo a allora il campo b)

Ovviamente, MVC è un paradigma disponibile in diverse varietà. Quello che descrivo qui è che MVC occupa solo il livello superiore, guarda questo articolo su Wikipedia

Oggi, MVC e MVP (Model-View-Presenter) simili sono modelli di progettazione Separation of Concerns che si applicano esclusivamente al livello di presentazione di un sistema più grande. In scenari semplici MVC può rappresentare il progetto primario di un sistema, raggiungendo direttamente il database; tuttavia, nella maggior parte degli scenari il controller e il modello in MVC hanno una dipendenza libera da un livello / livello di servizio o dati. Questo è tutto sull'architettura client-server

Se usi gli iniettori di dipendenza, la tua logica aziendale andrà a loro e quindi otterrai controller ordinati e puliti.