Ho creato una semplice applicazione Java MVC che aggiunge record a un database tramite moduli di dati.
La mia app raccoglie i dati, li convalida e li archivia. Questo perché i dati vengono acquistati online da diversi utenti. i dati sono per lo più di natura numerica.
Ora sui dati numerici archiviati nel database (server SQL), voglio che la mia app esegua calcoli e visualizzi i risultati. Lutente non è interessato a come vengono eseguiti i calcoli, quindi devono essere incapsulati. Lutente 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 stored procedure per lo stesso, ma voglio unapp a tre livelli.
Voglio che i dati che inserisco nel database come record, lavorino eseguendo calcoli su di esso. I dati originali dovrebbero rimanere inalterati, mentre i nuovi dati, dopo i calcoli, devono essere archiviati come un 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, dovrei inserirlo in nuovi file JavaBeans?
Commenti
- possibile duplicato di Rimanere OO e testabile mentre si lavora con un database
- La logica aziendale è alias di un ragazzo nel tuo team / dipartimento a cui chiedi come fare / operare su un modello. Ecco perché ‘ la logica aziendale può essere archiviata in una classe separata denominata logica aziendale. Lo stesso vale per la logica di presentazione, che è sinonimo di un designer che risponde alle tue domande su come formattare o visualizzare i componenti dellinterfaccia utente. Può esserci anche una logica dello sviluppatore (domande che chiedi e rispondi da solo o chiedi ai tuoi colleghi) che rappresenta una conoscenza su come creare e connettere i componenti di un programma insieme.
Risposta
La logica aziendale deve essere inserita nella modello e dovremmo puntare a modelli grassi e controller .
Come punto di partenza, dovremmo iniziare dalla logica del controller. Ad esempio: allaggiornamento , il controller dovrebbe indirizzare il codice al metodo / servizio che fornisce le tue modifiche al modello.
Nel modello, possiamo facilmente creare helper / classi di servizio in cui lapplicazione regole o calcoli aziendali può essere convalidata.
Un concetto riepilogo
-
Il controller è per la logica dellapplicazione. La logica specifica di come la tua applicazione vuole interagire con il ” dominio della conoscenza ” a cui appartiene.
-
Il modello è per la logica che è indipendente dallapplicazione . Questa logica dovrebbe essere valida in tutte le possibili applicazioni del ” dominio della conoscenza ” a cui appartiene.
-
Pertanto, è logico inserire tutte le regole di business nel modello.
Commenti
- bella risposta chiara e concisa ..
- @Yusubov, potresti spiegarmi la differenza tra la logica dellapplicazione e la logica aziendale
- @Moh, in breve queste sono parole dordine per aiutare descrivere i livelli di tecnologia in unapplicazione. La logica aziendale è fondamentalmente regole del sistema secondo specifiche funzionali. Ad esempio, loggetto A di tipo B deve avere attribuito C e D, ma non E. Application Logic è più una specifica tecnica, come lutilizzo di servlet Java e OJB per persistere in un database Oracle.
- Per favore elabora 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] - Se ho capito bene, larticolo citato fa riferimento alla ‘ logica dellapplicazione ‘ come ‘ logica aziendale ‘. Pertanto, tutto ciò che fa riferimento alla logica di business non deve essere inserito nel controller o nella vista.
Answer
Come sempre, dipende dalla complessità del progetto.
Nelle applicazioni banali, dove la complessità del modello di dominio è relativamente piccola, puoi 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 un modello, state introducendo uno stretto accoppiamento tra questi modelli.Man mano che le applicazioni continuano a crescere, questi modelli tendono a trasformarsi in god models, conoscendo troppo. E questo si trasformerà rapidamente in un grande pasticcio difficile da testare e mantenere. Quindi, in tal caso, è utile mettere la logica in un livello separato.
Quando si decide sullastrazione, tenere sempre in considerazione la complessità e gli scopi dellapp ed evitare uningegnerizzazione eccessiva. Per applicazioni banali / piccole, lintroduzione di più livelli di quelli necessari aumenta la complessità invece di ridurla.
Robert Martin (zio Bob) ha pubblicato un buon post sul blog su questo argomento: The Clean Architecture.
Commenti
- la domanda era specifica per MVC. la logica di business dovrebbe sempre essere nel modello. Il controller è solo un adattatore.
- MVC è uno dei termini più sovraccarichi del settore. Non ‘ t voglio entrare nelle stranezze di questo termine, poiché garantisce un libro. Solo, luso di MVC non ‘ implica che devi inserire ogni logica nei modelli.
- Dalla definizione di Steve Burbeck (team 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 di adattatore. - Se metti tutta la logica nel modello, ti ritroverai con migliaia di righe di disordine non gestibile. Stato lì. ‘ non è un peccato avere classi di utilità e un livello di servizio.
- Penso che ciò a cui stava arrivando jgauffin fosse che la domanda è specifica per MVC. Se accettiamo di visualizzare il sistema dalla prospettiva MVC e solo dalla prospettiva MVC, allora sì, tutta la logica aziendale appartiene al ” modello “, ma il ” modello ” può comprendere più classi e livelli, incluso ” classi di utilità ” e ” un livello di servizio ” . In altre parole, ‘ non diremmo che il livello di servizio è una parte del controller o della vista, quindi la soluzione migliore è il modello.
Risposta
Inserire la logica aziendale allinterno del modello potrebbe sembrare il modo migliore per procedere. Il controller riceve una chiamata dallapp Web remota. Il controller sul servizio Web MVC accetta la chiamata e reindirizza lesecuzione a un metodo in BL. Ora, Business Logic può essere contenuta nel “Model”, ma può anche essere posizionata in qualche altra cartella, ad esempio “Business Logic” . Quindi non esiste una regola rigida su dove sarà la logica aziendale.
Ho utilizzato un servizio web basato su MVC 3.0 e il contenitore della logica aziendale è il MODELLO .
Commenti
- Sono daccordo. Ottieni unapplicazione molto più flessibile quando il tuo modello è semplicemente una struttura di dati su cui agiscono altre classi di logica aziendale. Come semplice esempio, penso che sia un grosso fallimento dellapproccio di ASP.NET ‘ alla convalida utilizzando gli attributi. Se annoto la proprietà FirstName di una persona ‘ con lattributo Required, cosa succede se creo una vista amministratore in cui FirstName non dovrebbe essere richiesto? Un livello di logica aziendale dovrebbe utilizzare il modello e determinare le azioni appropriate per esso.