Logica aziendale in MVC [chiuso]
Risposte:
Le regole aziendali vanno nel modello.
Supponiamo che tu stia visualizzando email per una mailing list. L'utente fa clic sul pulsante "elimina" accanto a una delle e-mail, il controller notifica al modello di eliminare la voce N, quindi notifica la vista che il modello è stato modificato.
Forse l'e-mail dell'amministratore non dovrebbe mai essere rimossa dall'elenco. Questa è una regola aziendale, quella conoscenza appartiene al modello. La vista potrebbe in qualche modo rappresentare questa regola - forse il modello espone una proprietà "IsDeletable" che è una funzione della regola aziendale, in modo che il pulsante Elimina nella vista sia disabilitato per alcune voci - ma la regola stessa non è contenuta nella vista.
Il modello è in definitiva gatekeeper per i tuoi dati. Dovresti essere in grado di testare la tua logica aziendale senza toccare affatto l'interfaccia utente.
Pugno di tutto:
credo che stai mescolando il modello MVC e i principi di progettazione basati su n-tier.
L'uso di un approccio MVC non significa che non dovresti sovrapporre la tua applicazione.
Potrebbe essere utile vedere MVC più come un'estensione del livello di presentazione.
Se si inserisce il codice di non presentazione all'interno del modello MVC, molto presto si potrebbe finire con un design complicato.
Pertanto, suggerirei di inserire la logica aziendale in un livello aziendale separato.
Dai un'occhiata a questo: articolo di Wikipedia sull'architettura a più livelli
Dice:
Oggi, MVC e simili modelli-view-presenter (MVP) sono modelli di progettazione Separation of Concerns che si applicano esclusivamente al livello di presentazione di un sistema più grande.
Ad ogni modo ... quando si parla di un'applicazione Web aziendale, le chiamate dall'interfaccia utente al livello di logica aziendale devono essere inserite all'interno del controller (presentazione).
Questo perché il controller gestisce effettivamente le chiamate a una risorsa specifica, interroga i dati effettuando chiamate alla logica aziendale e collega i dati (modello) alla vista appropriata.
Mud ti ha detto che le regole aziendali vanno nel modello.
Anche questo è vero, ma ha confuso il modello (di presentazione) (la "M" in MVC) e il modello di livello dati di una progettazione di applicazioni basata su livelli.
Pertanto, è valido inserire le regole di business correlate al database nel modello (livello dati) dell'applicazione.
Ma non dovresti inserirli nel modello del tuo livello di presentazione strutturato MVC poiché questo vale solo per un'interfaccia utente specifica.
Questa tecnica è indipendente dal fatto che si utilizzi una progettazione guidata dal dominio o un approccio basato su script di transazione.
Lascia che lo visualizzi per te:
Livello di presentazione: Modello - Visualizza - Controller
Livello aziendale: logica di dominio - logica di applicazione
Livello dati: repository di dati - Livello di accesso ai dati
Il modello che vedi sopra significa che hai un'applicazione che utilizza MVC, DDD e un livello dati indipendente dal database.
Questo è un approccio comune per progettare un'applicazione Web aziendale più grande.
Ma puoi anche ridurlo per utilizzare un semplice livello aziendale non DDD (un livello aziendale senza logica di dominio) e un semplice livello dati che scrive direttamente in un database specifico.
È anche possibile eliminare l'intero livello dati e accedere al database direttamente dal livello aziendale, anche se non lo consiglio.
Questo è il trucco ... Spero che questo aiuti ...
[Nota:] Dovresti anche essere consapevole del fatto che oggigiorno esiste più di un "modello" in un'applicazione. Comunemente, ogni livello di un'applicazione ha il proprio modello. Il modello del livello di presentazione è specifico della vista ma spesso indipendente dai controlli utilizzati. Il livello aziendale può anche avere un modello, chiamato "modello di dominio". Questo è in genere il caso quando si decide di adottare un approccio basato sul dominio. Questo "modello di dominio" contiene sia dati che logiche aziendali (la logica principale del programma) ed è generalmente indipendente dal livello di presentazione. Il livello di presentazione di solito chiama il livello aziendale su un determinato "evento" (pulsante premuto ecc.) Per leggere o scrivere dati nel livello dati. Il livello dati potrebbe anche avere un proprio modello, che è in genere correlato al database.
La domanda è: come si adatta al concetto MVC?
Risposta -> Non lo fa!
Bene - lo fa un po ', ma non completamente.
Questo perché MVC è un approccio sviluppato alla fine degli anni '70 per il linguaggio di programmazione Smalltalk-80. A quel tempo le GUI e i personal computer erano abbastanza rari e il world wide web non era nemmeno stato inventato! La maggior parte dei linguaggi di programmazione e degli IDE di oggi sono stati sviluppati negli anni '90. A quel tempo i computer e le interfacce utente erano completamente diversi da quelli degli anni '70.
Dovresti tenerlo a mente quando parli di MVC.
Martin Fowler ha scritto un ottimo articolo su MVC, MVP e le GUI di oggi.
Il termine logica aziendale non è secondo me una definizione precisa. Evans parla nel suo libro Domain Driven Design di due tipi di logica aziendale:
- Logica di dominio.
- Logica dell'applicazione.
Questa separazione è secondo me molto più chiara. E con la consapevolezza che esistono diversi tipi di regole commerciali, arriva anche la consapevolezza che non vanno necessariamente tutti nello stesso posto.
La logica del dominio è una logica che corrisponde al dominio effettivo. Quindi, se stai creando un'applicazione di contabilità, allora le regole di dominio sarebbero regole riguardanti account, registrazioni, tassazione, ecc. In uno strumento di pianificazione software agile, le regole sarebbero cose come il calcolo delle date di rilascio in base alla velocità e ai punti della storia nel backlog, eccetera.
Per entrambi questi tipi di applicazione, l'importazione / esportazione CSV potrebbe essere rilevante, ma le regole di importazione / esportazione CSV non hanno nulla a che fare con il dominio effettivo. Questo tipo di logica è la logica dell'applicazione.
La logica del dominio va sicuramente nel livello del modello. Il modello corrisponderebbe anche al livello di dominio in DDD.
La logica dell'applicazione tuttavia non deve necessariamente essere posizionata nel livello del modello. Ciò potrebbe essere inserito direttamente nei controller oppure è possibile creare un livello applicazione separato che ospita tali regole. Ciò che è più logico in questo caso dipenderebbe dall'applicazione reale.
A1 : Business Logic Modelpartecipa MVC. Il ruolo di Modelè quello di contenere dati e logica aziendale. Controllerd'altra parte è responsabile di ricevere l'input dell'utente e decidere cosa fare.
A2 : A Business Rulefa parte di Business Logic. Hanno una has arelazione. Business Logicha Business Rules.
Dai un'occhiata Wikipedia entry for MVC. Vai a Panoramica dove menziona il flusso del MVCmodello.
Guarda anche Wikipedia entry for Business Logic. Si dice che Business Logicè composto da Business Rulese Workflow.
Come hanno sottolineato un paio di risposte, credo che ci siano alcuni malintesi sull'architettura multi-livello vs MVC.
L'architettura multilivello prevede la suddivisione dell'applicazione in livelli / livelli (ad es. Presentazione, logica aziendale, accesso ai dati)
MVC è uno stile architettonico per il livello di presentazione di un'applicazione. Per applicazioni non banali, la logica aziendale / le regole aziendali / l'accesso ai dati non devono essere collocati direttamente in modelli, viste o controller. Fare ciò significherebbe inserire la logica aziendale nel livello di presentazione e ridurre così il riutilizzo e la manutenibilità del codice.
Il modello è una scelta molto ragionevole per posizionare la logica di business, ma un approccio migliore / più sostenibile è quello di separare il livello di presentazione dal livello di logica aziendale e creare un livello di logica aziendale e chiamare semplicemente il livello di logica aziendale dai modelli quando necessario. Il livello di logica aziendale a sua volta chiamerà il livello di accesso ai dati.
Vorrei sottolineare che non è raro trovare codice che mescola la logica aziendale e l'accesso ai dati in uno dei componenti MVC, soprattutto se l'applicazione non è stata progettata utilizzando più livelli. Tuttavia, nella maggior parte delle applicazioni aziendali, troverai comunemente architetture multilivello con un'architettura MVC all'interno del livello di presentazione.
Questa è una domanda con risposta, ma darò il mio "un centesimo":
Le regole aziendali appartengono al modello. Il "modello" è sempre costituito da (separati logicamente o fisicamente):
- modello di presentazione - un insieme di classi che è adatto per l'uso nella vista (è adattato all'interfaccia utente / presentazione specifica),
- modello di dominio - la parte del modello indipendente dall'interfaccia utente e
- repository : la parte del "modello" sensibile alla memoria.
Le regole di business vivono nel modello di dominio, sono esposte in una forma adatta alla presentazione al modello "presentazione" e talvolta sono duplicate (o anche applicate) nel "livello dati".
Non ha senso inserire il proprio livello aziendale nel Modello per un progetto MVC.
Dì che il tuo capo decide di cambiare il livello di presentazione in qualcos'altro, verrai fregato! Il livello aziendale dovrebbe essere un assieme separato. Un modello contiene i dati che provengono dal livello aziendale che passano alla vista per essere visualizzati. Quindi, ad esempio, per posta, il modello si lega a una classe Person che risiede nel livello aziendale e chiama PersonBusiness.SavePerson (p); dove p è la classe Person. Ecco cosa faccio (manca la classe BusinessError ma andrebbe anche nel BusinessLayer):
Q1:
Le logiche aziendali possono essere considerate in due categorie:
Le logiche di dominio come i controlli su un indirizzo e-mail (unicità, vincoli, ecc.), Ottengono il prezzo di un prodotto per la fattura o calcolano il prezzo totale del carrello in base ai suoi oggetti prodotto.
Flussi di lavoro più ampi e complicati che sono chiamati processi aziendali, come il controllo del processo di registrazione per lo studente (che di solito include diversi passaggi e richiede controlli diversi e presenta vincoli più complicati).
La prima categoria entra nel modello e la seconda appartiene al controller . Questo perché i casi nella seconda categoria sono ampie logiche applicative e inserirle nel modello può mescolare l'astrazione del modello (ad esempio, non è chiaro se dobbiamo mettere queste decisioni in una classe di modello o in un'altra, poiché sono correlate A entrambi!).
Vedi questa risposta per una distinzione specifica tra modello e controller, questo link per definizioni molto precise e anche questo link per un buon esempio Android.
Il punto è che le note menzionate da "Mud" e "Frank" sopra possono essere sia vere che "Pete" (la logica aziendale può essere messa nel modello o nel controller, secondo il tipo di logica aziendale).
Infine, nota che MVC differisce da un contesto all'altro. Ad esempio, nelle applicazioni Android, vengono suggerite alcune definizioni alternative che differiscono da quelle basate sul web (vedi questo post per esempio).
Q2:
La logica aziendale è più generale e (come "deciclone" di cui sopra) abbiamo le seguenti relazioni tra loro:
regole aziendali log logiche aziendali
Perché non introdurre un livello di servizio. quindi il controller sarà snello e più leggibile, quindi tutte le funzioni del controller saranno azioni pure. puoi scomporre la logica aziendale secondo le tue necessità all'interno del livello di servizio. la riusabilità del codice è alta. nessun impatto su modelli e repository.
Modello = codice per le operazioni del database CRUD.
Controller = risponde alle azioni dell'utente e passa le richieste dell'utente per il recupero o l'eliminazione / l'aggiornamento dei dati al modello, in base alle regole aziendali specifiche di un'organizzazione. Queste regole aziendali potrebbero essere implementate nelle classi di supporto o, se non sono troppo complesse, solo direttamente nelle azioni del controller. Il controller infine chiede alla vista di aggiornarsi in modo da fornire un feedback all'utente sotto forma di un nuovo display o un messaggio come "aggiornato, grazie", ecc.,
Visualizza = UI generata in base a una query sul modello.
Non ci sono regole rigide e veloci su dove dovrebbero andare le regole aziendali. In alcuni progetti entrano nel modello, mentre in altri sono inclusi con il controller. Ma penso che sia meglio tenerli con il controller. Lascia che il modello si preoccupi solo della connettività del database.