Dove mettere la logica di business nella progettazione MVC?

Ho creato una semplice applicazione MVC Java che aggiunge record attraverso moduli di dati a un database.

La mia app raccoglie dati, li convalida e li memorizza. Questo perché i dati provengono online da utenti diversi. i dati sono principalmente di natura numerica.

Ora sui dati numerici archiviati nel database (server SQL), voglio che la mia app esegua calcoli e visualizzi i risultati. L'utente non è interessato a come vengono eseguiti i calcoli, quindi devono essere incapsulati. L'utente deve essere in grado di visualizzare solo i dati calcolati semplici (ad esempio, i dati della colonna A meno i dati della colonna B divisi per i dati della colonna C). So come scrivere le stored procedure per lo stesso, ma voglio un'app a tre livelli.

Voglio i dati che ho messo nel database come un record, su cui ho lavorato eseguendo calcoli su di esso. I dati originali dovrebbero rimanere inalterati, mentre i nuovi dati, dopo i calcoli, devono essere archiviati come nuovo record di entità nel database.

Dove devo scrivere il codice per questo calcolo in background? Dato che sono le regole e la logica aziendale, devo inserirlo in nuovi file JavaBeans?

— BriskLabs Pakistan
fonte

possibile duplicato di Staying OO e Testable mentre si lavora con un database

— moscerino

Risposte:

La logica aziendale dovrebbe essere inserita nel modello e dovremmo puntare a modelli fat e controller skinny .

Come punto di partenza, dovremmo iniziare dalla logica del controller. Ad esempio: al momento dell'aggiornamento , il controller deve indirizzare il codice al metodo / servizio che fornisce le modifiche al modello.

Nel modello, è possibile creare facilmente classi di supporto / servizio in cui è possibile convalidare le regole o i calcoli aziendali dell'applicazione .

Un riassunto concettuale

Il controller è per la logica dell'applicazione. La logica specifica di come l'applicazione desidera interagire con il "dominio della conoscenza" a cui appartiene.
Il modello è per la logica indipendente dall'applicazione . Questa logica dovrebbe essere valida in tutte le possibili applicazioni del "dominio della conoscenza" a cui appartiene.
Pertanto, è logico inserire tutte le regole aziendali nel modello.

— EL Yusubov
fonte

bella risposta chiara e concisa ..

— hanzolo

@Yusubov, per favore, potresti spiegarmi la differenza tra la logica dell'applicazione e la logica aziendale

— Mohamad

@Moh, in breve queste sono parole d'ordine per aiutare a descrivere i livelli di tecnologia in un'applicazione. La logica aziendale è fondamentalmente le regole del sistema in base alle specifiche funzionali. Ad esempio, l'oggetto A di tipo B deve aver attribuito C e D, ma non E. La logica dell'applicazione è più una specifica tecnica, come l'uso di servlet Java e OJB per persistere in un database Oracle.

— EL Yusubov,

Potresti approfondire queste parole:

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

[ php-html.net/tutorials/model-view-controller-in-php ]

— revo

Se ho capito bene, l'articolo citato si riferisce alla "logica dell'applicazione" come una "logica aziendale". Pertanto, tutto ciò che fa riferimento alla logica aziendale non deve essere inserito nel controller o nella vista.

— EL Yusubov,

Come sempre, dipende dalla complessità del progetto.

In applicazioni banali, in cui la complessità del modello di dominio è relativamente piccola, è possibile inserire la logica nei modelli e chiamarla un giorno.

Tuttavia, per applicazioni non banali con modelli complessi e molte regole aziendali, è meglio separare le cose un po 'di più.

Se si inserisce la logica aziendale che coinvolge più di un modello in un modello, si sta introducendo un accoppiamento stretto tra tali modelli. Mentre le applicazioni continuano a crescere, questi modelli tendono a trasformarsi god models, sapendo troppo. E questo si trasformerà rapidamente in un grande casino che è difficile da testare e mantenere. Quindi, in quel caso, è utile mettere la logica in un livello separato.

Quando decidi di astrazione, prendi sempre in considerazione la complessità e gli scopi della tua app ed evita l'eccessiva ingegneria. Per applicazioni banali / di piccole dimensioni, l'introduzione di più livelli di quelli necessari aumenta la complessità anziché ridurla.

Robert Martin (zio Bob) ha un buon post sul blog su questo argomento: The Clean Architecture.

— Hakan Deryal
fonte

la domanda era specifica per MVC. la logica aziendale dovrebbe essere sempre nel modello. Il controller è solo un adattatore.

— jgauffin,

MVC è uno dei termini più sovraccarichi del settore. Non voglio entrare nelle stranezze di questo termine, in quanto garantisce un libro. Solo, l'utilizzo di MVC non implica che è necessario inserire ogni logica nei modelli.

— Hakan Deryal,

Dalla definizione di Steve Burbeck (squadra Smalltalk):

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate

. Questa è una definizione dell'adattatore.

— jgauffin,

Se metti tutta la logica nel modello, finirai con migliaia di righe di pasticcio non mantenibile. Stato lì. Non è un peccato avere classi di utilità e un livello di servizio.

— asthasr,

Penso che a cosa stia arrivando il jgauffin è che la domanda è specifica per MVC. Se accettiamo di visualizzare il sistema dalla prospettiva MVC e solo dalla prospettiva MVC, quindi sì, tutta la logica aziendale appartiene al "modello", ma il "modello" può comprendere più classi e livelli, tra cui "classi di utilità" e "un livello di servizio". In altre parole, non diremmo che il livello di servizio fa parte del controller o della vista, quindi la soluzione migliore è il modello.

— DavidS,

Inserire la logica aziendale all'interno del modello potrebbe sembrare il modo migliore di procedere. Il controller riceve una chiamata dall'app Web remota. Il controller sul servizio Web MVC accetta la chiamata e reindirizza l'esecuzione a un metodo in BL. Ora, la logica di business può essere contenuta nel "modello", ma può anche essere posizionata in un'altra cartella, ad esempio "logica di business" . Quindi non esiste una regola rigida su dove sarà la logica aziendale.

Sto usando un servizio web basato su MVC 3.0 e il contenitore della business logic è il MODELLO MVC .

— Monty Python
fonte

Sono d'accordo. Si ottiene un'applicazione molto più flessibile quando il modello è semplicemente una struttura di dati gestita da altre classi di logica aziendale. Come semplice esempio, penso che sia un grosso fallimento dell'approccio di ASP.NET alla validazione usando gli attributi. Se annoto la proprietà FirstName di una persona con l'attributo Required, cosa succede se creo una vista di amministrazione in cui FirstName non dovrebbe essere richiesto? Un livello di logica aziendale dovrebbe utilizzare il modello e determinare le azioni appropriate per esso.

— xr280xr,