Quanta logica di business dovrebbe essere permessa nel livello controller?

Idealmente nessuno

Ma non è sempre possibile. Non posso darti numeri duri come il 20% o 10 linee, che è soggettivo al punto che non si può rispondere. Posso descrivere come utilizzo i modelli di progettazione e le circostanze che richiedono una leggera flessione.

Nella mia mente è interamente allo scopo dell'applicazione. Costruire una semplice API REST per postare? Dimentica la separazione netta o persino un motivo. Puoi sfornare una versione funzionante in meno di un'ora. Costruire qualcosa di più grande? Probabilmente è meglio lavorarci sopra.

Costruire sistemi confinati singolarmente è l'obiettivo. Se inizi a scrivere una logica di business specifica del modo in cui due sistemi interagiscono, è un problema. Senza guardare oltre, non posso esprimere un'opinione.

I modelli di design sono stampi, alcuni preferiscono rispettarli rigorosamente sulla base del codice principale e ben scritto. L'aderenza rigorosa a un pattern probabilmente non ti darà il codice cattivo , ma potrebbe richiedere più tempo e farti scrivere molto più codice.

I modelli di progettazione sono flessibili, regolali per soddisfare le tue esigenze. Piegali troppo e si rompono però. Conosci ciò che ti serve e scegli un modello di design più vicino a quello.

Il meno 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 accettano oggetti di dominio e ne creano i modelmodelli, ciò può ragionevolmente coesistere con il controller. Ma quello dovrebbe essere il codice che esiste solo per il beneficio delle viste corrispondenti. Se esiste una regola a livello aziendale sull'igienizzazione dei dati, dovrebbe esistere nel tuo dominio / livello di servizio (con i test delle unità approriate).

Il termine "logica aziendale" è spesso confuso perché le persone hanno opinioni diverse su cosa significhi. A mio avviso, il termine "business logic" copre due aree

• Logica del dominio
• Logica dell'applicazione

La logica di dominio è logica relativa all'area principale a cui si riferisce la tua attività commerciale, quindi se scrivi un'applicazione per i contabili, le regole fiscali, le regole di conservazione dei libri e così via fanno parte della logica del dominio.

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

Il tipo di "logica aziendale" che puoi inserire nel livello controller è Logica applicazione. Forse non tutta la logica applicativa dovrebbe andare lì. Ma non si dovrebbe mai inserire la logica di dominio nel livello controller. Ovviamente dovrebbe essere nel livello dominio.

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

I controllori dovrebbero essere molto leggeri sulla logica di dominio.

I controllori dovrebbero delegare attività come il recupero di un record dall'archivio dati mediante un livello di servizio / repository astratto e il trasferimento dei dati nell'archivio dati dallo stesso servizio (o relativo). Per quanto riguarda la meccanica e le lavorazioni più delicate tra quelle operazioni, di solito appartengono ad un posto diverso dal controller.

Spesso mi trovo ad aggiungere piccoli metodi di risanamento dei dati ai miei controller che salvano i dati nell'archivio e sebbene questa sia una soluzione efficace, non si adatta bene al ruolo previsto del controller. Idealmente, tutto ciò che modificherà, convalida o analizzerà il modello dovrebbe verificarsi 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.

Come molti altri concetti interessanti nella programmazione, MVC è un potente paradigma per portare la struttura e concentrarsi su una famiglia di strategie simili 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 sì che porti la struttura nel caos vista da una mente umana.

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

• Quanta logica dovrebbe andare in un controller?

• Se una vista dovrebbe contenere qualsiasi logica condizionale?

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

Queste sono tutte domande nate nel tentativo di regolare il codice per adattarlo all'idea concettuale di MVC in modo preciso e completo.

La mia risposta a voi è non provarci. MVC fornisce struttura. Costruisci la tua applicazione intorno a questa fondazione ma non aspettarti che si adatti perfettamente. Ci saranno delle deviazioni, è normale. Guarda per tenerli sotto controllo.

Da un punto di vista pragmatico ho scoperto che si finisce con la logica nel comportamento del controller o del controller nel modello quando si tenta di fare qualcosa per cui non esiste un buon approccio compatibile con lo schema. Detto di dubbio se stai scrivendo un'app che non ha una grande infrastruttura alle spalle.

Puoi andare in entrambi i modi, ma di solito cerco di pensare se è probabile che il bit strano venga visualizzato in più di un'azione del controller, se così va nel modello. Se questo non è chiaro, cerco di pensare se è più "appropriato" in un posto rispetto all'altro. In caso contrario, di solito lo inserisco nel modello solo per tenerlo fuori dal controller (preferenza personale per controller più piccoli e oggetti dati più potenti, YMMV)

Una terza opzione sarebbe quella di fare riferimento agli elementi dell'utilità come una classe di utilità separata, ma che è in qualche modo contro il modello e secondo l'opinione di molti.

Inoltre, solo perché non segui rigorosamente uno schema, non stai necessariamente flirtando con il disastro. A meno che non ti aspetti davvero che una quantità significativa di codice riutilizzi questo progetto, mi preoccuperei molto di più sul fatto che il progetto sia coerente con se stesso (ad esempio: non flip-flop su dove metti questi bit una volta che scegli una posizione) di una riscrittura che per qualche ragione vuole salvare parte della metà del progetto. Documento / commento dove & perché hai deviato dal modello comune e definisci il modello previsto per questa applicazione.

A un certo punto MVC era una deviazione dai modelli stabiliti.