Vantaggi dell'uso della logica aziendale nel modello

La chiave è:

Separazione delle preoccupazioni

In un mondo ideale vuoi un dato pezzo di codice per fare una cosa e farlo bene. Quindi vuoi provare ad evitare di mescolare logica di visualizzazione e logica di business e logica di archiviazione e tutto il resto.

Questa separazione offre una serie di benefici: la testabilità (come suggerito) è importante (anche se a mio avviso è quasi un bonus), ma anche il fatto che il codice dovrebbe essere più facile da capire a qualsiasi livello e quindi più facile per mantenere, che il modello / logica di business (in particolare) è più portabile (dal web all'app nativa) o che è possibile cambiare l'UX (ad esempio dalle pagine MVC a un'app javascript completamente separata usando un'API Web) - infine, se nient'altro, l'esperienza cumulativa di un numero enorme di programmatori ci dice che la separazione delle preoccupazioni è una buona cosa.

Sulle attuali prestazioni dell'hardware del server non dovrebbe esserci un problema a meno che non stiate facendo cose seriamente funky e quindi non volete essere legati nei livelli dell'interfaccia utente perché non potete quindi tentare di gestire il problema problemi di prestazioni in isolamento.

In primo luogo, è quasi sempre un errore discutere del posto della logica aziendale in termini di velocità del programma (almeno, quando i livelli del modello e del controller fanno parte dello stesso programma senza alcuna comunicazione di rete tra di loro). Se si verificano problemi di velocità, è possibile ottimizzarli sia nel livello del modello che nel livello del controller.

Molto più importante della velocità è in genere l'obiettivo di fornire al tuo programma una buona struttura, in cui si conosce la responsabilità di ciascun componente, in cui è possibile testare le cose da soli, evitando la ripetizione del codice quando si utilizza la stessa parte della logica aziendale è necessario due volte e così via.

Pertanto, la domanda per il posto migliore dovrebbe essere guidata dalla domanda "che tipo di logica aziendale?"

• la logica di business che controlla le interazioni degli utenti delle tue visualizzazioni appartiene tipicamente a un controller
• piccole parti della logica aziendale che si occupano principalmente di un oggetto business appartengono tipicamente a quell'oggetto e quindi sono posizionate nel modo migliore nel modello. Esempio: avere un oggetto "Persona" con attributi "FirstName" e "LastName", e devi ottenere il "nome completo" come concatenazione di FirstName e LastName, quindi una proprietà "FullName" di "Person" può essere una buona idea .
• per le parti più grandi della tua logica, indipendentemente dalle tue visualizzazioni, dovresti introdurre classi di controller separate.

Dove esattamente disegnare la linea dipende da te. C'è una discussione a lungo termine e aperta nella comunità su quanta logica dovrebbe essere nel modello e quanto nei controllori, vedi, ad esempio, qui: link

1. Testabilità.

Disaccoppiando l'interfaccia utente dal modello è più facile scrivere test solo sul modello. Basta testare contro le funzionalità di base, senza doversi preoccupare dell'interfaccia utente che si intromette (cosa che si può verificare, e ci sono modi per farlo, ma questo non è quello che stai chiedendo:).

Concetto di modello ....

Il modello gestisce il comportamento e i dati del dominio dell'applicazione, risponde alle richieste di informazioni sul suo stato (di solito dalla vista) e risponde alle istruzioni per cambiare stato (di solito dal controller). Nei sistemi basati sugli eventi, il modello notifica agli osservatori (di solito le viste) quando le informazioni cambiano in modo che possano reagire.

Visualizza il concetto ....

La vista rende il modello in una forma adatta per l'interazione, in genere un elemento dell'interfaccia utente. Più viste possono esistere per un singolo modello per scopi diversi. Una porta di visualizzazione ha in genere una corrispondenza uno a uno con una superficie di visualizzazione e sa come renderizzarla.

Concetto di controller ...

Il controller riceve l'input dell'utente e avvia una risposta effettuando chiamate su oggetti del modello. Un controller accetta input dall'utente e indica al modello e a una porta di visualizzazione di eseguire azioni basate su tale input.

MVC

guarda anche lo screenshot

Leggi attentamente e rispondimi se hai qualche domanda riguardante questo @shayan