Quanta logica aziendale dovrebbe essere consentita di esistere nel livello controller?

A volte abbiamo una logica di business rappresentata nel codice del controller delle nostre applicazioni. Questa è di solito una logica che differenzia quali metodi chiamare dal modello e / o quali argomenti passarli.

Un altro esempio di ciò è un insieme di funzioni di utilità esistenti nel controller che potrebbero funzionare per formattare o sanificare i dati restituiti dal modello, in base a un insieme di regole aziendali.

Funziona, ma mi chiedo se sta flirtando con il disastro. Se esiste una logica aziendale condivisa tra controller e modello, i due livelli non sono più separabili e qualcuno che eredita il codice potrebbe essere confuso da questa irregolarità nella posizione del codice relativo alla logica aziendale.

La mia domanda è: quanta logica aziendale dovrebbe essere consentita nel controller e in quali circostanze, se ce ne sono?

Idealmente nessuno

Ma questo non è sempre possibile. Non posso darti numeri concreti come il 20% o 10 righe, che è soggettivo al punto in cui non è possibile rispondere. Sono in grado di descrivere come uso i modelli di progettazione e le circostanze che richiedono una leggera flessione.

Nella mia mente dipende interamente dallo scopo dell'applicazione. Stai creando una semplice API REST in cui pubblicare? Dimentica la separazione pulita o anche un modello. Puoi sfornare una versione funzionante in meno di un'ora. Costruire qualcosa di più grande? Probabilmente è meglio lavorarci su.

L'obiettivo è costruire sistemi individualmente contenuti. Se si inizia a scrivere una logica di business specifica per l'interazione tra due sistemi, si tratta di un problema. Senza approfondire non posso dare un parere.

I modelli di progettazione sono stampi, alcuni preferiscono aderire rigorosamente a essi sulla base di un codice principale e ben scritto. L'adesione rigorosa a un modello probabilmente non ti darà un codice errato , ma potrebbe richiedere più tempo e farti scrivere molto più codice.

I modelli di design sono flessibili, adattali in base alle tue esigenze. Piegali troppo e si rompono però. Scopri di cosa hai bisogno e scegli un modello di design più vicino a quello.

Più piccolo possibile. Preferibilmente nessuno.

Il controller dovrebbe preoccuparsi di accettare la richiesta, chiedere al servizio di dominio corretto di elaborare la richiesta e consegnare la risposta alla vista corretta.

In tale processo, tutta la "logica aziendale" dovrebbe esistere nei servizi di dominio.

Se si dispone di funzionalità che prendono oggetti di dominio e ne creano modelli di visualizzazione, ciò può ragionevolmente coesistere con il controller. Ma quello dovrebbe essere il codice che esiste solo per il bene delle viste corrispondenti. Se esiste una regola a livello aziendale sulla sanificazione dei dati, dovrebbe esistere nel tuo dominio / livello di servizio (con i test di unità dell'apprendista).

Il termine "logica aziendale" è spesso confuso perché le persone hanno opinioni diverse su ciò che questo significa. A mio avviso, il termine "logica aziendale" copre due settori

• Logica di dominio
• Logica dell'applicazione

La logica di dominio è una logica correlata all'area principale a cui si riferisce la propria attività, quindi se si scrive un'applicazione per ragionieri, le regole fiscali, le regole di tenuta dei libri contabili, ecc. Fanno parte della logica del dominio.

La logica dell'applicazione è una logica correlata al fatto che si sta eseguendo un programma per computer. Può trattarsi di elementi quali esportazione di importazione CSV, procedure guidate, ecc. Potrebbe contenere anche elementi come la creazione di e-mail dimenticate.

Il tipo di "logica aziendale" che è possibile posizionare nel livello controller è Logica applicazione. Forse non tutta la logica dell'applicazione dovrebbe andare lì. Ma non dovresti mai posizionare la logica del dominio nel livello del controller. Questo dovrebbe ovviamente essere nel livello del dominio.

Stavi parlando della logica per formattare o disinfettare i dati. La formattazione deve essere sicuramente la logica dell'applicazione. La sanificazione, d'altra parte, potrebbe essere una logica di dominio, se la sanificazione dei dati si basa su regole di dominio. Dipende dal contesto.

I controller dovrebbero essere molto chiari sulla logica del dominio.

I responsabili del trattamento dovrebbero delegare attività come il recupero di un record dall'archivio dati tramite un livello di servizio / repository astratto e il passaggio dei dati nell'archivio dati dallo stesso servizio (o correlato). Per quanto riguarda la meccanica e il funzionamento più fine tra quelle operazioni, di solito appartengono a un posto diverso dal controller.

Mi ritrovo spesso ad aggiungere piccoli metodi di risanamento dei dati ai miei controller che salvano i dati nel negozio e sebbene questa sia una soluzione efficace, non si adatta bene al ruolo previsto del controller. Idealmente, tutto ciò che modifica, convalida o analizza il tuo modello dovrebbe avvenire molto vicino, se non all'interno, del modello stesso. Ad esempio, se è necessario "ripulire" un oggetto modello prima di memorizzarlo, considerare di avere un metodo SanitizeInputs () sul modello o come parte del servizio che gestisce la memorizzazione del modello.

Da un punto di vista pragmatico ho scoperto che o finisci con la logica nel tuo controller o il comportamento del controller nel tuo modello quando stai cercando di fare qualcosa per cui non esiste un buon approccio conforme al modello. Doppiamente se stai scrivendo un'app che non ha una grande infrastruttura dietro di essa.

Puoi andare in entrambi i modi, ma di solito provo a pensare se è probabile che lo strano bit si presenti in più di un'azione del controller, se così va nel modello. Se ciò non è chiaro, provo a pensare se è più "adatto" in un posto rispetto all'altro. In mancanza di solito lo inserisco nel modello solo per tenerlo fuori dal controller (preferenza personale per controller più piccoli e oggetti dati più forti, YMMV)

Una terza opzione sarebbe quella di fare riferimento agli elementi di utilità come una classe di utilità separata, ma questo è in qualche modo contrario al modello anche secondo l'opinione di molti.

Inoltre, solo perché non stai seguendo rigorosamente un modello non stai necessariamente flirtando con il disastro. A meno che non ti aspetti davvero una quantità significativa di riutilizzo del codice da questo progetto, mi preoccuperei molto di più che il progetto sia coerente con se stesso (cioè: non flip-flop su dove metti questi bit una volta scelta una posizione) di una riscrittura che per qualche motivo vuole salvare parte della metà del progetto. Documenta / commenta dove e perché ti sei allontanato dal modello comune e definisci il modello previsto per questa applicazione.

MVC era una deviazione dagli schemi stabiliti stessi ad un certo punto.

Come molti altri concetti interessanti nella programmazione, MVC è un potente paradigma per portare struttura e attenzione a una famiglia di strategie vicine o simili per implementare determinati scenari.

Come molti altri concetti di programmazione, MVC semplifica la realtà, elimina piccoli dettagli e fornisce un modello di wireframe grezzo da seguire. Come molte altre semplificazioni della realtà, fa funzionare portando la struttura nel caos visto da una mente umana.

Tuttavia, come molti altri concetti di programmazione, MVS è solo una semplificazione della realtà. Non è perfetto e non è accurato. Ecco perché non è possibile adattare uno scenario del mondo reale a un modello semplificato. Da qui nascono molte domande simili a questa.

• Quanta logica dovrebbe andare in un controller?

• Se una vista deve contenere una logica condizionale?

• Se un modello deve contenere dati aggiuntivi non trovati direttamente nelle entità aziendali?

Queste sono tutte domande nate nel tentativo di adattare il codice per adattarsi perfettamente e completamente all'idea concettuale di MVC.

La mia risposta è non provarci. MVC fornisce struttura. Costruisci la tua applicazione su questa base ma non aspettarti che si adatti perfettamente. Ci saranno deviazioni, è normale. Basta guardare per tenerli sotto controllo.