Perché inserire la logica aziendale nel modello? Cosa succede quando ho più tipi di archiviazione?

Ho sempre pensato che la logica aziendale dovesse essere nel controller e che il controller, poiché è la parte "centrale", rimane statico e che il modello / vista deve essere bloccato tramite interfacce. In questo modo è possibile modificare la logica aziendale senza influenzare nient'altro, programmare più modelli (uno per ciascun database / tipo di archiviazione) e una dozzina di visualizzazioni (ad esempio per piattaforme diverse).

Ora ho letto in questa domanda che dovresti sempre inserire la logica di business nel modello e che il controller è profondamente connesso con la vista.

Per me, questo non ha davvero senso e implica che ogni volta che voglio avere i mezzi per supportare un altro database / tipo di archiviazione devo riscrivere il mio intero modello inclusa la logica aziendale.

E se voglio un'altra vista, devo riscrivere sia la vista che il controller.

Qualcuno può spiegare perché questo è o se ho sbagliato da qualche parte?

La risposta di ElYusubov in gran parte la risolve , la logica del dominio dovrebbe andare nel modello e la logica dell'applicazione nel controller.

Due chiarimenti:

• Il termine logica di business qui è piuttosto inutile, perché è ambiguo. La logica di business è un termine generico per tutte le logiche che interessano gli uomini d'affari, separandole da semplici tecnicismi come il modo di archiviare elementi in un database o come renderli su uno schermo. Sia la logica di dominio ("un indirizzo email valido assomiglia a ...") sia i flussi di lavoro / i processi aziendali ("quando un utente si iscrive, chiede il suo indirizzo email") sono considerati logica aziendale, con il primo chiaramente appartenente al modello e quest'ultimo è la logica dell'applicazione che va nel controller.
• MVC è un modello per mettere roba su uno schermo e permettendo all'utente di interagire con esso, non specifica di archiviazione a tutti . La maggior parte dei framework MVC sono framework full stack che vanno oltre il semplice MVC e ti aiutano a memorizzare i tuoi dati, e poiché i dati che dovrebbero essere archiviati di solito si trovano nel modello, questi framework ti offrono modi convenienti per archiviare il tuo modello- dati in un database, ma ciò non ha nulla a che fare con MVC. Idealmente, i modelli dovrebbero essere indipendenti dalla persistenza e il passaggio a un diverso tipo di archiviazione non dovrebbe influenzare affatto il codice modello. Le architetture complete hanno uno strato di persistenza per gestirlo.

Tu e gran parte del mondo della programmazione sembra fraintendere quali sono i ruoli delle parti MVC. In breve, sono:

Modello = logica di dominio

Visualizza = logica di output

Controller = logica di input

Ciò significa che il modello è responsabile dell'intera logica aziendale: tutto ciò che è legato al disegno di widget su uno schermo, alla guida di una stampante, alla trasmissione di dati come HTML, all'analisi delle richieste HTTP, ecc. Ecc. Non appartiene al modello.

Tuttavia, molti dei moderni quadri cosiddetti "MVC" non eseguono affatto MVC o etichettano erroneamente le loro parti. Molto spesso, ciò che viene chiamato "modello" è il livello di persistenza del modello, mentre la logica aziendale si trova in quello che chiamano "controller"; il controller effettivo di solito è solo un punto di ingresso centrale con una tabella di routing e un po 'di codice nei singoli "controller" per inviare l'input che ricevono ai processi aziendali corretti. Ciò che questi framework chiamano "view" è in realtà un po 'di tutto: un po' di logica di presentazione (View), un po 'di input management e validazione (Controller), e un po' più di business logic (Model). La parte del leone della vista reale è generalmente chiamata "template".

Potresti anche voler leggere sull'architettura multilivello; dove MVC è un po 'unidirezionale (il flusso è Controller -> Modello -> Visualizza), Multi-Tier è una cosa a due vie (Presentazione -> Logica -> Dati -> Logica -> Presentazione), e parecchi i framework che fingono di fare MVC eseguono in realtà tre livelli, rietichettando Presentation to View, Logic to Controller e Data to Model.

Per isolare veramente la logica aziendale e renderla separata dall'infrastruttura del livello di presentazione, dovrebbe essere incapsulata dai servizi dell'applicazione. L'architettura MVC è un modo per implementare il livello di presentazione e dovrebbe rimanere in tale ambito, delegando tutta la logica aziendale a questi servizi applicativi. Pensa ai modelli di vista come adattatori tra la vista e i dati che devono essere visualizzati e o letti. Il controller media l'interazione tra modelli di vista, viste e servizi applicativi che ospitano la logica aziendale.

I servizi applicativi implementano casi d'uso aziendali e sono disaccoppiati dal livello di presentazione, sia esso MVC o qualcos'altro. A loro volta, i servizi applicativi possono ospitare script di transazione o una progettazione guidata dal dominio .

Per l'archiviazione, il servizio applicativo può fare riferimento a un repository o qualsiasi astrazione di un meccanismo di persistenza. Diverse implementazioni possono essere supportate astrattando l'accesso ai dati in un'interfaccia. In genere, queste astrazioni perdono e sono solo parzialmente trasportabili attraverso le implementazioni ed è spesso un tentativo inutile di raggiungere la piena portabilità.

AGGIORNARE

Il mio suggerimento si basa sull'architettura esagonale . In un'architettura esagonale, il tuo modello di dominio (logica aziendale) è al centro. Questo nucleo è incapsulato da servizi applicativi che fungono da facciata . I servizi applicativi sono semplici classi che hanno metodi corrispondenti ai casi d'uso nel tuo dominio. Per una discussione approfondita sui servizi applicativi, dai un'occhiata ai servizi in Domain-Driven Design . L'esempio di codice contiene un PurchaseOrderServiceche è un servizio applicativo per un dominio di acquisto. (Si noti che un servizio applicativo non implica l'uso di una progettazione guidata dal dominio.)

In un'architettura esagonale, un livello di presentazione MVC è un adattatore tra il modello di dominio (logica aziendale) e una GUI. Il modello di dominio non è a conoscenza del livello di presentazione, ma il livello di presentazione è a conoscenza del modello di dominio.

Questa soluzione ha sicuramente parti mobili rispetto a una soluzione che pone la logica di business nel controller e dovresti valutare gli svantaggi e i vantaggi. Il motivo per cui lo suggerisco è perché preferisco mantenere la logica aziendale disaccoppiata dal livello di presentazione al fine di combattere la complessità. Questo diventa più importante man mano che l'applicazione cresce.

Dipende da cosa intendi per logica di business. Qualsiasi "logica" che dia significato ai contenuti del modello dovrebbe essere nel modello. Nella domanda collegata, la risposta più votata sembra definire la "logica di business" come qualsiasi cosa relativa ai dati; questo ha senso dal punto di vista che i dati di un'azienda sono affari suoi!

Una volta ho visto un esempio del creatore di Rails (penso) che stava succedendo esattamente questo, senza inserire la "logica aziendale" nel modello. Il suo esempio era una classe di controller e un metodo per la registrazione e il login dell'app: una password fornita in testo normale veniva crittografata prima di essere inserita o interrogata nel modello (un database).

Non riesco a pensare a un esempio migliore di qualcosa che non è la logica del controller e che appartiene direttamente al modello.

Il modello potrebbe essere un'interfaccia per una miriade di archivi dati, alleviando i problemi di portabilità. È qui che si potrebbe trovare confusione sul fatto che l'interfaccia del modello sia in realtà il "controller".

In generale, il controller collega il modello e la vista (che sono la carne e le patate dell'app.) Nello sviluppo di Cocoa può essere semplicistico al punto in cui il controller viene gestito tramite la GUI XCode (oggetti controller e associazioni).

La sezione "Design Patterns" di GoF su MVC, liberamente citata:

La triade di classi MVC viene utilizzata per creare interfacce utente in Smalltalk-80. Il modello è l'oggetto dell'applicazione, la vista è la presentazione dello schermo e il controller definisce il modo in cui l'interfaccia utente reagisce all'input dell'utente. MVC disaccoppia le viste e i modelli stabilendo un protocollo di sottoscrizione / notifica tra di loro. Il diagramma seguente mostra un modello e tre viste. Abbiamo lasciato fuori i controller per semplicità.

MVC si basa sulle interfacce utente. L'attenzione si concentra sul modello e sulla vista: definizione e visualizzazione dei dati. Nota il "protocollo di iscrizione / notifica": è qui che entra in gioco il tuo controller. Puoi creare tutte le visualizzazioni che desideri; fintanto che aderiscono al protocollo non dovrai mai toccare il modello o il controller.

Se parli in particolare dello sviluppo web, IMHO molti framework Web popolari sono veloci e sciolti con il termine MVC e le sue definizioni dei componenti.

Perché non introdurre un livello di servizio?

Quindi il controller sarà snello e più leggibile, quindi tutte le funzioni del controller saranno azioni pure.

È possibile scomporre la logica aziendale in base alle esigenze all'interno del livello di servizio. La riusabilità del codice è migliore e non vi è alcun impatto su modelli e repository.