Dov'è la M in MVC?

Sto cercando di refactificare la mia applicazione in MVC, ma sono bloccato sulla parte M.

In un'app supportata da database, il modello è implementato nel codice dell'app, giusto?

Ma allora, cosa c'è nel database - non è anche questo il modello?

(Non sto usando il database come un semplice archivio oggetti - i dati nel DB sono un bene aziendale).

Sì, sia il modello nel codice che il database sono il "Modello".

Il modello ha a che fare con ciò che l'applicazione "È" e il controller è ciò che "fa". Qualsiasi codice relativo alla persistenza diretta nel database è considerato il Modello.

Nota: MVC è un modello , quindi non pensarci troppo. È facile ottenere tutto super nel fare MVC nel modo giusto, ma alla fine, è solo una mentalità! Significa mantenere la logica di business al di fuori del database e dell'interfaccia utente. Prima di MVC, le persone inserivano la logica aziendale nelle loro pagine Web quando doveva trovarsi sul server, oppure avrebbero avuto un sacco di script attivi nel database che eseguivano la logica aziendale insieme al codice di persistenza. MVC è stato creato per indurre le persone a iniziare a pensare in un modo che aiuta a rendere riutilizzabile il loro codice, quindi non lasciarti coinvolgere troppo dai dettagli.

Trygve Reenskaug scrisse i documenti iniziali che descrivevano il modello MVC nel 1978. Il Modello nella sua descrizione era il modello a oggetti che rappresentava oggetti, fenomeni e concetti del mondo reale. Nel tuo scenario di un'applicazione supportata da database, il modello è una proiezione dei tuoi dati. Per dirla semplicemente, il modello sono le classi e le loro relazioni di cui si occupa l'applicazione.

In pratica, di solito ci sono due modelli utilizzati in MVC, il modello di dominio (che cosa sta mappando al tuo database) e il modello di applicazione (chiamato anche modello di visualizzazione nella terminologia odierna). Il modello di applicazione è una proiezione del modello di dominio che contiene anche dati specifici della vista per il rendering della vista. Questo approccio si chiama MMVC . Il controller interagisce direttamente con il modello di dominio e presenta un modello di applicazione alla vista. Nel modello MVVM vengono combinati il ​​modello applicativo e il controller.

1. Non è necessario un database per MVC. Se il tuo modello parla al database, va benissimo. Potrebbe anche persistere in un file flat o non persistere affatto.

2. Il modello è il punto in cui i dati sono archiviati nella memoria dell'applicazione. Ti consigliamo inoltre di utilizzare il modello per eseguire calcoli e convalide sui suoi dati. Ad esempio, hai un modello di FinancePayment, con proprietà come tasso di interesse, termine e principio. È possibile aggiungere un metodo getMonthlyPayment () al modello per calcolare il pagamento mensile. Non vorrai farlo nel controller o nella vista.

3. La vista dovrebbe essere ragionevolmente stupida, o non avere alcuna logica, o usando solo un semplice binding di dati (vedere i modelli di Vista passiva e Supervisione del controller sul sito di Martin Fowler ). La vista genera eventi quando l'utente fa cose, come fare clic su un pulsante.

4. Il controller è responsabile della gestione degli eventi (esegui un po 'di codice quando l'utente fa clic sul pulsante Salva), e imposta le proprietà del modello e dice al modello di caricare e salvare se stesso (se usa la persistenza). Il controller non dovrebbe eseguire calcoli sui dati del modello. Tuttavia, nel controller, è possibile eseguire alcuni calcoli per conto della vista, ad esempio "if model.profit () <0 then widget.colour = 'red'"

5. Dovresti essere in grado di passare a una versione della riga di comando dell'applicazione senza modificare i modelli e senza perdere la funzionalità dei modelli.

un. Probabilmente dovresti essere in grado di passare a una versione mobile dell'applicazione (al contrario di una versione desktop) cambiando solo le visualizzazioni (e non i controller o i modelli). Dovresti essere in grado di testare l'unità di modelli e controller senza un framework di test della GUI.

Il modello è il codice che ha una connessione a V e C nel front-end e alla memoria persistente (può essere qualsiasi cosa, dai file ai database SQL / NoSQL) nel back-end. Non è solo il codice che carica da db e memorizza in db (che è uno dei fraintendimenti del modello), è anche il codice che fa effettivamente tutto il "dominio": seleziona, filtra, modifica, calcola, decide dati. Include tutta la logica non UI dell'applicazione.

Adottare una visione molto semplicistica e idealistica.

Il modello è generalmente visto come un modello del dominio (approssimativamente, il business), non come un modello dei dati. Questi possono sembrare simili, ma non sono completamente legati l'uno all'altro.

La vista dovrebbe essere un modello del front-end dell'applicazione e il controller dovrebbe essere un modello del flusso da una vista all'altra.

La logica aziendale deve essere interamente incapsulata nel modello, sia nel database che nel codice. Sebbene alcune logiche aziendali possano essere ripetute nella vista o nel controller, per vari motivi, dovrebbe essere possibile (e sicuro) rimuovere completamente questi due componenti e sostituirne un front-end diverso.

Per quanto ne so, MVC è solo la descrizione del modello architettonico dell'applicazione client. L'immagine qui in Wikipedia mostra solo questo:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Ovviamente, quando hai parti della tua applicazione implementate in "procedure memorizzate", anche quel codice del database può far parte del modello, o persino del controller (a seconda di cosa fa il codice). Ma se così non fosse, allora il database è chiaramente "al di fuori di MVC", proprio come lo hai dichiarato.

But then, what is in the database -- is that not also the model?

No non lo è. " Il modello gestisce il comportamento e i dati del dominio dell'applicazione". Spesso, il Modello si aggancia a un database sì, ma non è assolutamente un requisito. Il modello è un nuovo livello tra l'applicazione e il database. Il backend potrebbe essere un insieme di oggetti Mock, XML o qualsiasi altra cosa che supporti la persistenza dei dati.

Disaccoppiando i livelli ti concedi una flessibilità molto maggiore per utilizzare le migliori pratiche di unit test, rendi il codice più gestibile (EG SQL viene sostituito da Oracle) tra gli altri vantaggi.

Lo stesso vale per il controller. MVC definisce il controller come un intermediario tra i due livelli. Non esiste un "livello aziendale" definito in MVC. Piuttosto, aggiungi il tuo. MVC non incapsula tutti i livelli necessari per creare la maggior parte delle applicazioni. È solo una linea guida generale per la struttura di base.

Queste separazioni sono fondamentali per consentire il funzionamento dell'inversione del controllo.

Il database è un dettaglio di implementazione del modello. Il modello dovrebbe essere un modello di dominio completo e dovrebbe combinare dati e processi. La separazione dovrebbe essere tra i problemi di differenza e non tra un processo e i dati relativi a quel processo.

Vedi anche: http://martinfowler.com/bliki/AnemicDomainModel.html

In realtà è molto semplice, "Modello" rappresenta l'astrazione per l'interfaccia dati. È per questo:

• I database sono considerati parte del Modello , ma non il modello stesso
• I dati del Modello possono provenire da database, file, servizi Web o addirittura essere derisi.
• Le classi di modelli in MVC, HMVC o framework simili dovrebbero archiviare le query (vedere il principio "modello fat, controller skinny" [ 1 ] [ 2 ] [ 3 ])

E, se ho ragione, ecco perché quando qualcuno fa riferimento a modelli al di fuori del contesto MVC, qualcuno probabilmente fa riferimento alla struttura dei dati (cioè schema ).

Penso che la M contenga un po 'di logica e memorizzi i dati nel DB. Il controller invoca quale modulo verrebbe eseguito e questo modulo eseguirà logiche e memorizzerà i dati nel DB (può avere un livello persistente) e quindi questo modulo restituisce il valore a V.

La M (odel) nell'MVC dovrebbe catturare il modello di business / dominio in un unico posto.

Ciò dovrebbe idealmente includere le regole aziendali del dominio e la sua struttura.

Il C (controller) dovrebbe idealmente occuparsi solo di mediare le informazioni del modello di business sulla presentazione (ad es. La View) e acquisire l'input dell'utente da V (iew) per avviare cambiamenti nello stato del modello.

Il livello del database gestisce solo (o meglio dovrebbe trattare solo) la persistenza dello stato del modello in un determinato momento.

In quanto tale, non è qualcosa che appartiene alla parte Modello o Controller del modello MVC, ma piuttosto è una preoccupazione completamente separata che può essere implementata implicitamente persistendo in modo trasparente qualsiasi modifica al modello (in funzione della facciata, fornendo il interazioni con il tuo Modello con il Controller) o come è fatto più spesso, chiamato esplicitamente dal Controller dopo che ha terminato di apportare mutazioni al modello.

Il modello in un mondo ideale dovrebbe contenere solo una logica aziendale, modella un oggetto reale come una Casa. Tuttavia, in quasi tutte le circostanze, il modello deve conservare i propri dati in alcuni archivi.

Le interazioni tra il modello e i dati memorizzati possono avvenire su un livello dati separato o direttamente nel modello, come nel caso di un ORM (Object Relational Mapper). In altre parole, il modello si collega direttamente al database o passa i suoi dati ad un altro oggetto di "accesso ai dati" che si collega al database.

Un ORM (Object Relation Mapper) associa i campi nella tabella del database agli attributi dell'oggetto modello, fornendo getter e setter. In questo caso non esiste un livello dati separato e il modello è direttamente responsabile della persistenza dei dati.

Ecco un esempio di Ruby che utilizza ActiveRecordun ORM popolare:

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Priceè un campo nella housestabella che viene automaticamente rilevato dal ActiveRecordquale aggiunge un getter e setter all'oggetto. quandosave viene chiamato, il valore dell'attributo price viene mantenuto nel database.

Dal mio punto di vista, il pro di avere un livello dati è che puoi ottenere un punto in cui puoi manipolare i dati prima che arrivino al modello, il modello ha meno preoccupazioni, ha meno responsabilità. Ad esempio potrebbe essere necessario combinare i dati provenienti da diverse origini dati non compatibili, questo è qualcosa che un ORM non può gestire facilmente.

L'aspetto principale è che è un altro livello di astrazione da gestire, se non ne hai bisogno, non preoccuparti, mantienilo semplice. Meno parti in movimento, meno errori.

Si hai ragione.

(Controller vista modello)

Un'architettura per la creazione di applicazioni che separa i dati (modello) dall'interfaccia utente (vista) e l'elaborazione (controller).

In pratica, le viste e i controller MVC sono spesso combinati in un singolo oggetto perché sono strettamente correlati. Secondo MSDN

Il controller interpreta gli input del mouse e della tastiera dall'utente, informando il modello e / o the view to change as appropriate.

Controlla questo diagramma:

Ad esempio, il codice del controller convalida una richiesta di dati e ne provoca la restituzione in una vista. Gli oggetti del controller di visualizzazione sono legati a un solo modello; tuttavia,a model can have many view-controller objects associated with it.