ASP.NET MVC: la logica aziendale dovrebbe esistere nei controller?

Question

Derik Whitaker ha pubblicato un articolo un paio di giorni fa che ha colpito un punto che sono stato curioso per qualche tempo: la logica aziendale dovrebbe esistere nei controller?

Finora tutte le demo ASP.NET MVC che ho visto hanno messo l'accesso al repository e la logica aziendale nel controller. Alcuni addirittura lanciano anche la convalida. Ciò si traduce in controller gonfiati abbastanza grandi. È davvero questo il modo di usare il framework MVC? Sembra che questo finirà con un sacco di codice duplicato e logica sparsi su diversi controller.

Answer 1

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

Ad esempio, invece di avere:

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

Preferirei avere:

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

Ciò presuppone che le imposte siano calcolate da un servizio esterno e richieda al modello di conoscere 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 del genere.

Answer 2

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

Answer 3

Questa è una domanda affascinante.

Penso che sia interessante il fatto 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 è un modello nel senso di Gang Of Four. Piuttosto, è un paradigma che il programmatore debba aggiungere modelli in se stanno creando qualcosa al di là di un'app giocattolo.

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

Una risposta più lunga è che è necessario riflettere sul design del layer del modello prima di spostare la logica da controller a 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 diventi gonfio.

Answer 4

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

  

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

Answer 5

La logica di business non deve essere contenuta nei controller. I controller dovrebbero essere il più magri possibile, idealmente seguire lo scalpiccio:

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

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

Quindi dove metto la mia logica aziendale? Nel modello.

Che cos'è il modello? Questa è una buona domanda. Si prega di consultare articolo Microsoft Patterns and Practices (complimenti ad AlejandroR per una ricerca eccellente). Qui ci sono tre categorie di modelli:

• Visualizza modello : si tratta semplicemente di un data bag, con una logica minima, se del caso, per passare i dati da e verso le visualizzazioni, contiene una convalida del campo di base.
• Modello di dominio : modello fat con logica aziendale, opera su entità dati singole o multiple (ovvero entità A in un dato stato rispetto all'azione sull'entità B)
• Modello di dati : modello sensibile all'archiviazione, la logica contenuta in una singola entità si riferisce solo a tale entità (ovvero se il campo a quindi il campo b)

Naturalmente, MVC è un paradigma che esiste in diverse varietà. Quello che descrivo qui è MVC che occupa solo il livello superiore, vide questo articolo su Wikipedia

  

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

Answer 6

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