Se scrivo un'applicazione e decido di sviluppare solo una singola interfaccia grafica per esso, e non intendo mai sviluppare più GUI, allora per gli standard odierni è corretto non usare il pattern MVC o il pattern MVP, o in generale preferisci il pattern MVC per software orientato agli oggetti con output? Il vantaggio del pattern MVC è proprio quello di poter programmare molte GUI diverse. Tuttavia, se si prevede di sviluppare solo una singola GUI dall'inizio, questo vantaggio verrà eliminato.
Il vantaggio di poter programmare su molte GUI diverse è ridotto al minimo se si dispone di una sola GUI. Ma comprendi che hai più GUI se aggiorni la tua interfaccia grafica.
Il punto di disaccoppiamento non è semplicemente la capacità di lavorare con più componenti. È così che gli altri componenti possono cambiare senza influenzare il resto del sistema. Quindi, se stai cercando una situazione in cui puoi ignorare questi vantaggi, hai bisogno di una scusa migliore della tua abilità magica di prevedere che non ci saranno mai "GUI multiple". Devi anche prevedere che quello che fai non avrà mai bisogno di cambiare.
Certamente puoi farlo. So di aver scritto un sacco di codice "non testabile" da buttare via prima. Abbi solo quello che stai facendo.
Il punto principale di MVC e le relative architetture è di strutturare il flusso di dati e comportamenti nell'applicazione. In particolare, vogliamo separare la presentazione dei dati dalla rappresentazione interna e dalla logica di business, perché ciò rende più facile lavorare sulla GUI o sulla logica di business. Potrebbero esserci altri vantaggi (come il riutilizzo della logica di business o una migliore testabilità), ma quelli sono secondari.
In alcuni piccoli casi starai bene senza questi schemi. Ma per un programma più complicato, avrai bisogno di un'architettura chiara per evitare una "grande palla di fango". MVC / MVP / MVVM sono alcune scelte popolari per quell'architettura. Disaccoppiare le interfacce esterne dalla logica interna è una grande idea, è persino usato al di fuori delle GUI.
In primo luogo, applaudo il tuo approccio a considerare i trade-off, anche per cose che sembrano dogmaticamente parte del nostro pensiero al giorno d'oggi.
Risposta breve: Sì , assolutamente, se conosci cosa farai, non c'è assolutamente alcun motivo per separare artificialmente le cose che naturalmente appartengono insieme. Mi piacciono gli oggetti e la loro rappresentazione nell'interfaccia utente.
Risposta lunga: dipende da cosa intendi per MVC. Se intendi il significato corrente al giorno d'oggi, per avere una struttura dati pura ("Modello") che alcune procedure ("Controller") escano avanti e indietro, allora sicuramente non ti aiuteranno. In effetti, ciò renderà la tua applicazione molto più difficile da mantenere, poiché qualsiasi modifica nell'oggetto "business" effettivo si propagherà esponenzialmente attraverso queste strutture.
Tuttavia, fare tutto negli oggetti sarebbe anche sbagliato. Gli oggetti dovrebbero avere solo una funzionalità di visualizzazione sufficiente a non dover consentire agli oggetti esterni di accedere ai propri dati interni, ma non tanto da avere a che fare con dettagli irrilevanti come il colore, la dimensione del font, cose del genere.
Leggi altre domande sui tag object-oriented mvc