Il pattern MVC annulla altri pattern di progettazione?

Per prima cosa dovresti notare che MVC è un pattern relativo all'interfaccia utente. Mi ci sono voluti diversi anni per capire questo schema correttamente. Anche MVC, non è un modello reale, è più simile a un approccio generale, perché esistono varie implementazioni.

Ad esempio, Model-View-Presenter è un'incarnazione su pattern MVC con responsabilità leggermente modificate, molto adatto per applicazioni desktop. In ogni caso, il presentatore in questo approccio implementerebbe un modello di osservatore e la vista è oggetto osservabile. Inoltre, di solito, quando la vista è in qualche modo complessa, vorrei introdurre un oggetto ViewData , o il cosiddetto ViewModel , che contiene i dati visualizzati e immessi dall'utente. Anche questa vista caso diventa un osservatore per questo oggetto ViewModel .

In caso di applicazioni desktop di grandi dimensioni, non è possibile rimanere con un buon codice usando solo pattern MVC. Ci sarà troppa responsabilità per ogni livello. Quel caso MVC è solo una parte superiore dell'intera applicazione. Direi un piccolo esempio dalla propria esperienza.

Tutta la logica aziendale implementata dai comandi , comandi restituiti da CommandFactory ( pattern di fabbrica ). C'è anche la logica ortogonale per i comandi, come controllare i diritti di accesso e la registrazione delle azioni commerciali eseguite. Questa parte ortogonale utilizza intensamente il pattern Decorator . Nel mezzo dell'applicazione c'è un modello dello stato attuale dei dati, che non è un semplice modello mappato su database, ma un modello che ha un comportamento correlato ai processi aziendali sotto il cofano. Questo modello è un gruppo di oggetti osservabili, che osserva il livello dell'interfaccia utente (pattern MVP). La creazione esatta dell'oggetto e il ciclo di vita sono controllati dai modelli di iniezione ServiceLocator / Dependency.

Detto questo, quando un'applicazione diventa sempre più grande e diventa più complessa, devi dividerla in parti il più possibile indipendenti, in modo da coinvolgere più persone in un progetto. Per ridurre la complessità e non soffrire di una sindrome NIH (Non-inventata-Qui) ci sono molti modelli che darti un modo di implementare una soluzione per i tipici problemi di progettazione che è ben comprensibile per altri programmatori.

Il pattern MVC è un pattern composto composto da più pattern:

• Il Modello utilizza il modello Observer per mantenere aggiornate le viste e il controller.
• Puoi trovare il modello di strategia nella vista e nel controller in quanto la vista riguarda solo la visuale aspetti e delega tutti i comportamenti dell'interfaccia al controller
• E puoi trovare il pattern composito nella vista se lavori con finestre nidificate, ecc.

Quindi, per rispondere alla tua domanda, l'MVC già si confonde con alcuni schemi di progettazione e ciò solleva la complessità, in quanto non si parla nemmeno di aggiungere altri modelli.

** modifica **
Iniziare a leggere un po 'e trovare un po' più di informazioni sull'argomento.
Se hai bisogno di più schemi o di un diverso approccio ai pattern MVC, sembra che sia tutta una serie di pattern che adattano, sostituiscono o aggiungono pattern al MVC esistente per tutti i tipi di situazioni:

• MVC ,
• MVA ,
• MVP ,
• PAC ,
• Model-Delegate

No, perché la maggior parte dei modelli di progettazione non impone come dovrebbe essere organizzato il codice. Invece descrivono i ruoli che le classi possono avere in una particolare interazione e danno nomi comuni a quei ruoli per facilitare la comunicazione con altri sviluppatori.

Il fatto che il modello MVC suggerisca una certa organizzazione delle classi non significa che non è possibile applicare altri modelli di progettazione all'interno o attraverso tale organizzazione.
Ad esempio, all'interno di una triade MVC, è possibile utilizzare il pattern Observer per consentire alle classi Model di informare le relative classi View sugli aggiornamenti del modello. Questo è interamente all'interno della struttura del pattern MVC, perché il Modello non ha alcuna conoscenza su quale Visualizza le classi che deve informare, solo che dovrebbe informare quelle classi che sono registrate (e possono essere Visualizza le classi, ma ugualmente bene, possono essere altre classi di modelli).
In modo simile, puoi anche utilizzare il modello Abstract Factory per creare classi View specifiche basate su parametri a cui il Controller non dovrebbe preoccuparsi (ad esempio, se hai una classe View separata per ogni lingua supportata).