Possiamo dire che MVC è sottosistema (o sottoinsieme, sotto-architettura) di architettura client-server ?
Possiamo dire che MVC è sottosistema (o sottoinsieme, sotto-architettura) di architettura client-server ?
No.
MVC si riferisce al design e alla struttura di un'applicazione in quanto riguarda il flusso interno di dati e l'eventuale presentazione di tali dati.
È del tutto ortogonale se l'applicazione è un server, o è un client, oppure è sia un client che un server.
MVC è un pattern di progettazione dell'interfaccia utente che si affianca ad altri pattern di design equivalenti come MVP e MVVM ( note: , di "equivalenti", intendo solo che raggiungono un obiettivo molto simile, tuttavia essi realizzare questo obiettivo in modi molto diversi).
Una cosa che tutti questi pattern UI hanno in comune è che descrivono semplicemente la struttura di un'applicazione UI (che può dipendere anche dalla tua scelta di framework UI - alcuni framework si prestano a schemi particolari fornendoti un po 'di quello 'incollare' out-of-the-box).
Le applicazioni risultanti create con questi modelli possono essere o meno collegate in rete; nessuno di questi modelli ha nulla a che fare con la rete o l'architettura client-server. Esistono altri modelli per questo tipo di cose.
Le C ontroller e V parti di MVC correlate si riferiscono al modo in cui la logica dell'interfaccia utente è separata dall'aspetto e dal layout di un'interfaccia utente, mentre M odel è "tutto il resto".
Le viste dovrebbero essere generalmente stupide - essendo una rappresentazione visiva concreta di tutto ciò che l'utente vedrà e interagirà con. Le viste generalmente non contengono alcuna logica. Le viste in genere descrivono (tra le altre cose) widget, colori, caratteri, immagini, testo, layout, oltre a semplici collegamenti a un controller.
I controllori sono una rappresentazione più astratta dell'interfaccia utente senza componenti visive. Tendono ad essere strettamente correlati (ma non dipendenti) dalla Vista. I controller sono destinati alla logica dell'interfaccia utente e allo stesso tempo sono indipendenti dalla vista concreta (disaccoppiata).
Un controller dovrebbe sapere cosa fare quando viene premuto un pulsante, tuttavia quel controller non dovrebbe avere alcuna conoscenza di quel pulsante o di altri widget. Sarà responsabile della logica per gli eventi dell'interfaccia utente in entrata, come i clic del mouse / del pulsante. Dovrebbe anche gestire la logica per modificare lo stato di una vista, come decidere quando abilitare / disabilitare un pulsante o quando mostrare un messaggio all'utente. Ancora una volta, non dovrebbe avere alcuna conoscenza specifica su quei widget, sarà solo responsabile della logica (cioè prendere la decisione su se e quando qualcosa sull'interfaccia utente dovrebbe cambiare).
A causa della relazione implicita tra una vista e un controller, è comune vederli esistenti in-tandem, vale a dire un controller per ogni vista e una vista per ogni controller. (Tuttavia non è obbligatorio, solo una convenzione comune).
La parte Modello di MVC è un termine generico che indica "il resto della tua applicazione" .
I modelli potrebbero contenere uno o nessuno dei seguenti elementi:
Se la tua applicazione fa parte di un sistema più ampio, il modello è probabilmente parte del tuo livello di applicazione. In una piccola applicazione autonoma, il modello può essere il tuo livello di business logic principale. Nelle applicazioni estremamente piccole e semplici, il modello potrebbe anche essere solo il tuo livello dati.
I modelli dovrebbero essere totalmente agnostici per le viste / i controllori: un modello dovrebbe ignorare che viene utilizzato per un'applicazione GUI; quindi tende ad essere poca o nessuna relazione tra il numero di Modelli in un'applicazione rispetto al numero di Viste / Controllori. I modelli rappresentano il vero 'lavoro' e contengono gli oggetti / entità che effettivamente fanno sì che l'applicazione faccia tutto ciò che deve fare.
Leggi altre domande sui tag software mvc client-server