Le implementazioni MVC possono differire nei dettagli di progettazione e devono ancora essere considerate implementazioni MVC? [chiuso]

Non sono sicuro di cosa dirti in base a ciò che stai chiedendo.

La definizione del pattern MVC è uno di questi termini interpretati in vari modi, che sono tutti accettabili?

Bene, si. Voglio dire, ogni concetto ha una storia, giusto? Quindi, alla fine degli anni '80, gli sviluppatori Smalltalk hanno coniato il termine "MVC", e aveva molte delle caratteristiche che ci si aspetta: un modello che tiene lo stato dei dati, una vista responsabile della presentazione e della gestione dell'interfaccia utente e un controller che coordina i due.

Tuttavia, quando entra nei dettagli dell'implementazione, troverai molta varietà. Ora, sentirai ragazzi duri di GoF dire che solo la definizione di GoF è propriamente chiamata "MVC", ma personalmente non sono d'accordo, perché ho visto cose che assomigliano a MVC con molte varianti (chi possiede cosa, a chi è permesso parlare con chi, ecc.)

In realtà, vorrei davvero andare oltre e dire che "MVC" è molto simile al triangolo è quello di costruire l'architettura. È una forma (o in questo caso un insieme di tre relazioni) che fornisce una caratteristica importante - la separazione delle preoccupazioni.

Ho visto app create in modo tale che ciascuno dei componenti MVC THEMSELVES abbia classi simili a MVC. (Ad esempio, avrai una meta visione, un meta-controller e un meta-modello, e forse la meta-vista ha un modello per come accede ai suoi dati di configurazione, una vista per il rendering effettivo dei controlli e un controller questa è l'interfaccia esterna ai meta componenti).

Quindi visualizzo MVC come un elemento più di una cosa limitata con una sola implementazione valida.

Penso che la tua domanda non sia affatto risolvibile e finirai per avere tutte le risposte diverse basate sull'opinione pubblica. Non puoi sostanzialmente confrontare una definizione che in realtà non stai condividendo con noi - potrei avere una diversa comprensione di MVC, con tutte le implementazioni conosciute / sconosciute .

Le persone di solito fanno Esperimento con quello che hanno. Ciò potrebbe semplicemente portare a migliaia di applicazioni creative o mal progettate, tuttavia è necessario per il miglioramento.

Anche le persone hanno Comprensione delle stesse cose. Ecco perché apprezziamo Lavoro di gruppo . Un modello di design è anche un work-on-progress come ogni altra cosa in questo mondo. Non puoi saltare direttamente da MVC a MVC migliore in un giorno. Quello che vedi è il modo naturale di Apprendimento e Creazione .

Anche la maggior parte delle volte devi mescolare schemi di design per ottenere quello che vuoi. Potrebbe essere possibile implementare solo MVC per applicazioni più piccole, ma ci sono molti casi in cui è necessario mescolare il tuo MVC - o qualsiasi altra cosa, con altri modelli di progettazione. Questo potrebbe costringerti a cambiare alcuni aspetti del tuo MVC. Questo potrebbe confondere le persone, o potrebbero persino odiarti, ma questo è il modo in cui apprendiamo e viviamo: prova ed errore.

Forse un semplice esempio è in ordine.

La maggior parte delle implementazioni MVC ha una funzionalità chiamata "convenzione sulla configurazione". Ciò significa che alcuni valori di configurazione possono essere "assunti". Ad esempio, considera questo metodo di controller in ASP.NET MVC:

public View Index()
{
    return View();
}

Questo bit di codice (in assenza di numerosi dettagli aggiuntivi per semplicità) restituisce la vista "Indice", poiché il controller presume che si stia restituendo la vista con lo stesso nome del metodo del controller.

E se specificassi esplicitamente la vista?

public View Index()
{
    return View("Index");
}

Restituisce ancora la vista "Indice", ma stavolta ho espresso esplicitamente la mia intenzione. Non uso più "convenzione sulla configurazione", tuttavia.

Questo lo rende meno "MVC"? Certo che no.

Naturalmente, ci sono diversi gradi di conformità, e potrebbe esserci un momento in cui si è allontanati dallo "spirito e dall'intenzione" di MVC fino a un punto in cui non è più plausibile chiamarlo ancora MVC.

Le Winform non possono mai essere chiamate MVC, anche se ci sono modi per scriverlo (e le librerie per supportarlo) che possono emulare Model-View-Presenter.