Quando si progetta un'applicazione su Model-View-Controller (MVC), cosa c'è nella casella degli strumenti?

I diagrammi sono utili per aiutare a visualizzare il flusso di dati. I dati sono alla base di praticamente tutti i programmi. Ben fatto, UML ti mostra dove sono memorizzati i dati ( Il modello ), cosa sta guardando ( il controller ) e come potrebbe essere presentato ( il vista ).

Un esempio concreto di un sistema MVC potrebbe essere un'applicazione per blog. I dati come le voci del blog, i commenti e simili potrebbero essere archiviati in un database. Questa è la parte del modello. La porzione vista sarebbe un insieme di routine che costruiscono l'html per le pagine. Questi non sarebbero completi, sarebbero solo un framework, quindi se fossero eseguiti senza input, produrrebbero alcuni elementi visivi statici e alcune scatole vuote. Sono responsabili per la presentazione estetica del contenuto.

Il controllore legherebbe i due insieme richiedendo dati dal database e passandoli alle routine html per la visualizzazione, accettando l'input dell'utente tramite le pagine html e facendo ulteriori richieste di visualizzazione dei dati.

Un aspetto importante di questo paradigma è che le interfacce presentate dal framework di visualizzazione e dal database possono essere generali. Se il metodo per ottenere un articolo è sempre getArticle (ArticleID), non importa come viene implementato il backend, che si tratti di un database SQL, un hash db o un set di file flat. Tutto ciò che deve accadere è che i dati degli articoli grezzi vengano consegnati.

Allo stesso modo, il software di visualizzazione deve essere in grado di gestire solo i dati grezzi. Questo è uno dei motivi per cui il CSS è importante e l'idea di markup è importante. Se i dati dell'articolo hanno solo marcatori semantici, come paragrafo, divisione e così via, ed evita di nominare caratteri o colori o altri attributi estetici, è possibile utilizzare le stesse interfacce per una vista che gestisce l'estetica in modo completamente diverso. Ad esempio, potrebbe renderlo in braille o pronunciarlo.

Spero che questo aiuti e non è solo un'altra ricapitolazione di altre spiegazioni che hai letto.

È una specie di strana domanda. Una delle principali caratteristiche dei modelli di progettazione è il contesto in cui vengono applicati. Secondo me, non inizi con un modello di progettazione, inizi con un contesto.

OK, diciamo, per amor di discussione, MVC è ciò di cui hai bisogno. Cosa stai costruendo? Applicazione web? In questo ambito, la toolbox è o un framework o un set di componenti, sia esso Struts, Spring MVC, Rails o Zend (o centinaia di altri). Nella maggior parte dei casi già incorporano MVC e devi seguire un modo prescritto di fare le cose in modo da non violare i concetti MVC.

(Questa non è una risposta diretta alla tua domanda sugli strumenti di progettazione, ma è invece una risposta ai tuoi commenti sullo sviluppo multipiattaforma con MVC. )

Lo schema MVC separa i dati e la relativa logica strettamente associata (il modello) dalla logica aziendale (il controller) dalla logica di visualizzazione (la vista).

Pertanto, durante la programmazione per OS X e iOS, sarete in grado di utilizzare esattamente lo stesso modello e il codice del modello, richiedendo modifiche minime al codice del controller, lasciando la maggior parte delle modifiche alla fine della vista.

Aggiunta nel web, se hai usato il Cappuccino Web Framework o GNUstepWeb ci sarebbero più modifiche sul fine del modello, ma la separazione MVC consentirebbe comunque a gran parte del codice del controller di essere uguale o simile.

Obiettivo-C e Ruby on Rails , per me stesso.