L'idea principale alla base di OOP è unificare i dati e il comportamento in una singola entità: l'oggetto. Nella programmazione procedurale ci sono dati e algoritmi separatamente che modificano i dati.
Nel modello Model-View-Controller i dati e la logica / gli algoritmi sono collocati in entità distinte, rispettivamente il modello e il controller. In un approccio OOP equivalente, il modello e il controller non dovrebbero essere collocati nella stessa entità logica?
MVC è un esercizio in Separazione delle preoccupazioni , un'architettura dell'interfaccia utente. È un modo per correggere la complessità che può verificarsi nelle interfacce utente a causa della presentazione non separata dal contenuto .
In teoria, tutti gli oggetti possono avere un comportamento che opera sui dati che contengono e che i dati e il comportamento rimangono incapsulato . In pratica, un determinato oggetto OOP può o non può avere una logica che corrisponde ai suoi dati, o potrebbe non avere alcuna logica (un Dati Trasferisci oggetto , ad esempio).
In MVC, la logica aziendale va nel modello, non nel controller. Il controller è in realtà solo un intermediario per incollare la vista e il modello. Quindi nel modello, puoi avere dati e comportamenti nello stesso posto.
Ma anche questo accordo non garantisce una fusione rigorosa di dati / comportamenti. Gli oggetti contenenti solo dati possono essere gestiti da altre classi contenenti solo la logica, e questo è un uso perfettamente accettabile di OOP.
Ti darò un esempio specifico. Questo è un po 'forzato, ma diciamo che hai un oggetto Currency , e quell'oggetto ha la capacità di rappresentarsi in qualsiasi valuta disponibile, ancorato al dollaro. Quindi avresti metodi come:
public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }
... e questo comportamento verrebbe incapsulato con l'oggetto Valuta.
E se volessi trasferire la valuta da un conto a un altro o depositare una certa valuta? Questo comportamento sarebbe anche incapsulato nell'oggetto Valuta? No, non lo farebbe. I soldi nel tuo portafoglio non possono trasferirsi dal tuo portafoglio nel tuo conto bancario; hai bisogno di uno o più agenti (un bancomat o un bancomat) per aiutarti a ottenere quei soldi nel tuo account.
Quindi quel comportamento sarebbe incapsulato in un oggetto Teller , e accetterebbe Currency e Account oggetti come input, ma non conterrebbe alcun dato stesso, tranne forse un po 'di stato locale (o forse un oggetto Transaction ) per aiutare a elaborare gli oggetti di input.
MVC funziona con un livello di astrazione molto più elevato rispetto ai singoli oggetti, e in effetti ciascuno dei tre (modello, vista e controller) è in genere costituito da molti oggetti che hanno sia dati sia comportamenti .
Gli oggetti che incapsulano dati e comportamenti sono un buon elemento fondamentale per i programmi in generale non significa che sia il modello migliore a tutti i livelli di astrazione e per tutti gli scopi.
OOP non limita le interazioni tra oggetti che hanno ciascuno i propri dati e il proprio comportamento.
Pensa ad un'analogia con una formica e una formica: il comportamento di una singola formica (correre tutto il giorno, portando cibo) è diverso dal comportamento della colonia generale (trova il posto più desiderabile, crea più formiche). Il pattern MVC descrive la struttura sociale desiderata di una colonia di formiche, mentre OOP guida il design delle singole formiche.
OOP riguarda anche Separazione delle preoccupazioni , ovvero separare ruoli / responsabilità differenti in oggetti diversi.
MVC si separa in questi componenti:
Quindi queste responsabilità sono chiaramente distinte e dovrebbero essere effettivamente separate in più entità.
In the Model-View-Controller pattern the data and the logic/algorithms are placed in distinct entities, the model and the controller respectively.
Modello e controller sono due ruoli distinti. Un modello ha sia stato sia logica, e un controller ha sia stato che logica. Il fatto che comunichino non interrompe l'incapsulamento di nessuno dei due: il controllore non sa o cura come il modello memorizza i suoi dati, o cosa fa ai dati quando il controller recupera o aggiorna parte di esso. Il modello non conosce o cura ciò che il controller fa con i dati forniti dal modello.
Pensa in questo modo: se gli oggetti non possono passare i dati avanti e indietro senza interrompere l'incapsulamento, potresti davvero avere solo un oggetto!
In an equivalent OOP approach shouldn't the model and the controller be placed in the same logical entity?
MVC è un approccio OOP - in particolare, è una ricetta per decidere come usare gli oggetti per organizzare in modo efficace un programma. E no , il modello e il controller non dovrebbero essere la stessa entità. Un controller consente la separazione tra modello e vista. Mantenere il modello e la vista indipendenti l'uno dall'altro rende entrambi più testabili e più riutilizzabili.
MVC è uno schema che descrive un modo ragionevole in cui gli oggetti interagiscono; non è di per sé una meta-classe. A questo proposito, OO riguarda la descrizione dei comportamenti e dei dati delle entità e il modo in cui dette entità interagiscono. Non si tratta di unificare l'intero sistema in un unico oggetto.
Il controller non rappresenta il comportamento di un modello. I controllori rappresentano complessivamente il comportamento dell'intera applicazione _ ciò che un utente può fare e ciò che un utente può vedere.
È sbagliato visualizzare controller e modelli come uno. Hanno scopi diversi, semantica diversa e quindi non dovrebbero essere unificati in un unico oggetto.
Il livello del modello non è semplicemente un dato più che il livello del controller è semplicemente logico.
Il livello controller avrà una raccolta completa di oggetti per i suoi scopi. Ci saranno oggetti per ricevere input dalla vista e per trasformare quell'input in una forma che il modello può elaborare. Il framework Java Struts ne ha un buon esempio nel suo modello Action / Form. Il modulo viene popolato con l'input dell'utente e quindi passato all'azione. L'azione prende quei dati e li usa per manipolare il modello.
Allo stesso modo, il livello Model non consiste interamente di dati. Prendi un oggetto Utente, ad esempio: potresti aver bisogno di codice che ottiene un utente da un database, o codice per associare un utente a un ordine, o per verificare che l'indirizzo dell'utente sia all'interno dell'area dei servizi della tua azienda ... ottieni il immagine. Questa non è logica del controllore. È una logica aziendale, e molti hanno portato a suddividere il loro livello Model in diversi livelli, come i livelli Service o Manager per la logica aziendale, un livello DAO (Database Access Object) per l'accesso al database e altri.
MVC non è un metodo per organizzare le singole operazioni del modello. Funziona a un livello più alto di quello - è un metodo per organizzare come si accede all'applicazione. View è per la presentazione di dati e azioni umane per la sua manipolazione, il Controller è per la traduzione tra le azioni dell'utente e le varie visualizzazioni e il Modello è il luogo in cui risiedono i dati aziendali e le ragioni di business per esistere.
Il punto di OOP è raggruppare insieme dati e funzionalità che appartengono insieme . Un calcolo basato su alcuni dati non sempre appartiene a tali dati.
In MVC la funzionalità per visualizzare una parte di dati (vista) viene mantenuta separata dai dati (modello). Perché? In particolare, è possibile modificare la logica del display senza dover modificare i dati sottostanti. Semplifica la modifica della visualizzazione ogni volta che è necessario eseguire una presentazione diversa degli stessi dati o quando le caratteristiche dell'hardware del display cambiano: o quando si passa da Windows a Linux; o quando vuoi che due persone abbiano due modi diversi di guardare gli stessi dati.
MVC non è in conflitto con OOP - in realtà è derivato da una corretta applicazione dei principi orientati agli oggetti.
Credo che tu stia confondendo dati persistenti legati a un oggetto modello con i dati dell'applicazione dai database con cui il modello interagisce. Un modello contiene logica aziendale e regole per lavorare con i database e condurre transazioni. Potrebbe impostare e controllare i flag di stato interno come se ci sia una vendita oggi, se l'utente si qualifica per lo stato VIP e quindi la logica di ramo di conseguenza quando arriva il momento di accedere, impostare o manipolare i dati o effettuare un acquisto. Sono quelle bandiere di cui stiamo parlando quando discutiamo di oggetti in termini di incapsulamento di un insieme di metodi e valori o dati persistenti.
Proprio come l'oggetto modello mantiene i dati per stabilire quali regole di business sono in gioco, un controllore dovrebbe, IMO, conservare i dati generali dello stato dell'applicazione pertinenti a come deve comportarsi l'app, ad esempio se l'utente è connesso o disporre di dati validi della carta di credito. I metodi del modello determinano lo stato di queste cose in primo luogo, ma è logico che il controllore mantenga le segnalazioni pertinenti al flusso generale delle app se non si applicano a come viene condotta l'attività o vengono condotte transazioni di dati. Una volta stabilito che non sono connessi, non disturbare nemmeno il modello con i controlli dello stato dell'utente fino a quando non viene risolto un altro tentativo di accesso.
Allo stesso modo con un oggetto vista appropriato rispetto ai modelli HTML più tipici che vedi nella maggior parte dei framework web lato server. Una volta caricate le preferenze di colore dell'utente, dovrebbe essere la vista che trattiene i dati e li esegue. Il caricamento, la convalida e la modifica delle impostazioni sono tutti problemi del modello, ma dovrebbero essere solo problemi di modello una volta finché i cambiamenti non si verificano.
IMO, niente dice che i controllori non possono essere oggetti compositi con viste e modelli come oggetti aggregati interni. Questo ha davvero senso se si applica MVC su una scala più piccola come una fabbrica di widget UI poiché il controller è il luogo ideale per esporre un'interfaccia a oggetti di livello superiore mentre nascondono i dati e i dettagli logici di come interagiscono la Vista e il Modello. Non ha senso per gli oggetti di app monolocali in cui il controller è davvero l'oggetto di livello più alto.
A quanto ho capito L'argomento è l'architettura basata sui componenti rispetto a OOP. E senza entrare nella guerra religiosa, penso che entrambi stiano descrivendo la stessa cosa; solo guardandolo da diverse angolazioni.
Ad esempio, l'intero punto di OOP / OOD è rendere il codice più modulare e riusabile. Sì?
Quale è esattamente l'obiettivo dell'architettura basata sui componenti. Quindi sono più simili di qualsiasi altra cosa.
Penso che MVC sia solo la naturale evoluzione di OOP e oserei dire; un modo migliore per organizzare i tuoi oggetti, la separazione delle preoccupazioni e il riutilizzo del codice.
Sono in ritardo per questa festa e, considerando tutte le risposte prima della mia, ammetto che non ho molto di nuovo da offrire. Ma mi sembra che la domanda non riguardi il modello in sé ma l'implementazione. MVC in sé e per sé non si presta a una particolare metodologia. In effetti, posso facilmente immaginare un codice orientato alla procedura in un pattern MVC (che è quello che sentivo che stavi insinuando).
Quindi, penso che la vera domanda sia; siamo più inclini al codice procedurale quando utilizziamo il pattern MVC.
(e forse otterrò solo voti bassi?)
Non è anti, ma anche OOP non è richiesto per MVC.
Perché i controller, che di solito sono rappresentati da classi, non contengono dati. Per il quale sarebbero sufficienti le funzioni pure.
Se si va oltre e si separano i dati dal comportamento, ad esempio diciamo che i modelli funzionano solo sui dati del database, che recuperano ogni volta che viene chiamata la loro funzione (che è responsabile della manipolazione dei dati) (invece di memorizzare qualche tipo di dati nei campi istanza), quindi si può dire lo stesso per i modelli.
Andando oltre, se si prende il livello di vista di un'applicazione e lo si divide in modo simile, in realtà si concluderà che MVC non ha nulla a che fare con OOP, ed è completamente possibile scrivere l'implementazione MVC senza alcun dolore usando solo approccio procedurall.
Nel mio parere l'OOP ha un inconveniente che dal momento che (dati e comportamento) sono modellati come un'unica entità (Classe) questo mostra più effetto di accoppiamento rispetto alla coesione. Mentre invece MVC ha un modello che contiene ... (Fagioli, DAO, Altre classi logiche), Controller che specifica il modo in cui il controllo deve viaggiare e Views per determinare come devono essere mostrati i dati in modo separato. Sulla base di questo, indipendentemente dal fatto che il progetto sia troppo grande per essere preparato, può essere facilmente realizzato come entità separata diversa dalla combinazione di OOP. Il problema è risolto in uno schema logico, proprio come la strategia divide n conquer e MVC lo segue al massimo.
Leggi altre domande sui tag object-oriented design mvc