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

La risposta di ElYusubov principalmente lo inchioda, la logica di dominio dovrebbe entrare nel modello e nella logica dell'applicazione nel controller.

Due chiarimenti:

• Il termine business logic è piuttosto inutile qui, perché è ambiguo. La logica aziendale è un termine generico per tutte le logiche a cui le persone di business si preoccupano, separandole da meri aspetti tecnici come come archiviare materiale in un database o come renderlo su uno schermo. Entrambe le logiche di dominio ("un indirizzo email valido sembra ...") e i flussi di lavoro / processi aziendali ("quando un utente si iscrive, richiedi il suo indirizzo email") sono considerati business logic, con il primo chiaramente appartenente al modello e quest'ultimo è la logica dell'applicazione che entra nel controller.
• MVC è uno schema per mettere roba su uno schermo e consentire all'utente di interagire con esso, non specifica affatto memoria . La maggior parte dei framework MVC sono framework stack completi che vanno oltre il semplice MVC e aiutano a memorizzare i dati, e poiché i dati che dovrebbero essere archiviati sono di solito presenti nel modello, questi framework offrono metodi convenienti per archiviare il modello. dati in un database, ma questo non ha nulla a che fare con MVC. Idealmente, i modelli dovrebbero essere ostinati alla persistenza e il passaggio a un diverso tipo di archiviazione non dovrebbe assolutamente influire sul codice modello. Le architetture complete hanno un livello di persistenza per gestire questo.

Tu e molte parti del mondo della programmazione sembra fraintendere qual è il ruolo 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 è correlato al disegno di widget su uno schermo, alla guida di una stampante, all'emissione di dati come HTML, all'analisi di richieste HTTP, ecc. ecc. non appartiene modello.

Tuttavia, molti dei moderni cosiddetti framework "MVC" non fanno proprio 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 il "controllore"; il controller attuale è di solito solo un punto di accesso 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: una logica di presentazione (View), un po' di gestione e convalida degli input (Controller) e qualche altra logica di business (Model). La parte del leone della vista attuale è solitamente chiamata "templates".

Si potrebbe anche voler leggere sull'architettura multi-livello; dove MVC è un po 'unidirezionale (il flusso è Controller - > Model - > View), Multi-Tier è una cosa a due vie (Presentazione - > Logica - > Dati - > Logica - > Presentazione ) e alcuni framework che fanno finta di fare MVC eseguono effettivamente presentazioni a vista a tre livelli, relabeling alla vista, logica al controller e dati al modello.

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

I servizi di applicazione implementano i casi di utilizzo aziendale e sono disaccoppiati dal livello di presentazione, sia che si tratti di MVC o di qualcos'altro. A loro volta, i servizi applicativi possono ospitare script di transazione o design basato sul dominio .

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

Aggiorna

Il mio suggerimento si basa sull'architettura Hexagonal . In un'architettura esagonale, il tuo modello di dominio (business logic) è al centro. Questo nucleo è incapsulato da servizi applicativi che fungono da facciata . I servizi applicativi sono classi semplici che hanno metodi corrispondenti a casi d'uso nel tuo dominio. Per una discussione approfondita sui servizi applicativi dare un'occhiata a Servizi in Design guidato da domini . L'esempio di codice contiene un PurchaseOrderService che è un servizio di applicazione per un dominio di acquisto. (Si noti che un servizio applicativo non implica l'uso di un design basato sul dominio.)

In un'architettura esagonale, un livello di presentazione MVC è un adattatore tra il modello di dominio (business logic) 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 certamente parti in movimento di una soluzione che pone la logica aziendale nel controller e si dovrebbero valutare gli svantaggi ei vantaggi. Il motivo per cui lo suggerisco è perché preferisco mantenere la logica di business disgiunta dal livello di presentazione per combattere la complessità. Questo diventa più importante man mano che l'applicazione cresce.

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

Una volta ho visto un esempio del creatore di Rails (credo) che stava procedendo esattamente su questo - non mettendo "la logica del business" nel modello. Il suo esempio era una classe di controller e un metodo per la registrazione e il login delle app: una password fornita in chiaro veniva crittografata prima di essere inserita o interrogata sul modello (un database).

Non riesco a pensare ad un esempio migliore di qualcosa che non sia la logica del controllore e che appartenga direttamente al modello.

Il modello potrebbe essere un'interfaccia per una miriade di archivi dati, alleggerendo i problemi di portabilità. È qui che si può trovare confusione su wether o meno l'interfaccia del modello è in realtà il "controller".

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

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

The MVC triad of classes is used to build user interfaces in Smalltalk-80. The Model is the application object, the View is its screen presentation, and the Controller defines the way the UI reacts to user input. MVC decouples views and models by establishing a subscribe/notify protocol between them. The following diagram shows a model and three views. We've left out the controllers for simplicity.

MVC è interamente basato sulle interfacce utente. L'attenzione si concentra sul modello e sulla vista: definizione e visualizzazione dei dati. Nota il protocollo "subscribe / notify protocol": qui entra in gioco il tuo controller. Puoi costruire tutte le viste che vuoi; a condizione che aderiscano al protocollo, non dovrai mai toccare il modello o il controller.

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