Modello di dominio vs Visualizza modello

Hai chiesto esattamente la domanda giusta: "Perché?"

MVC, MVP, MVVM e probabilmente mille deviazioni minori di quelle ... Ci sono così tanti modelli di progettazione là fuori, e le differenze sono molto sottili. L'unico modo per capire chiaramente come progettare il livello GUI della tua applicazione è probabilmente quello di arrendersi, raccogliere i tuoi requisiti e pesarli l'uno contro l'altro. Ad esempio,

• Hai bisogno di test GUI automatizzati? In che misura?
• I tuoi schermi includono comportamenti "complessi" che non sono facilmente coperti dall'associazione dati? Quanti?
• Devi essere indipendente dalla piattaforma?
• Quali componenti vorresti riusare? Ad esempio, la tua applicazione si rivolge a schermi di dimensioni molto diverse ma vuoi riutilizzare la logica di business per tutti loro?

Esempio:

Se sai che non eseguirai test automatici e miri solo alla piattaforma Swing (cioè PC con una gamma relativamente ristretta di risoluzioni dello schermo), non preoccuparti di suddividere il codice in tre classi e creare uno Swing- modello di vista indipendente. Non ne ottieni nulla.

D'altro canto, se sviluppi un'applicazione GWT che richiede test automatici perché hai una logica di business non banale, probabilmente utilizzerai l'accoppiamento libero che MVP ti offre per poter eseguire i test in modo leggero ( cioè, senza componenti GWT in un ambiente Java puro).

Riguarda i requisiti specifici della tua applicazione e stack tecnologico ... E questo è probabilmente il motivo per cui ci sono così tante reincarnazioni dello stesso modello.

Una risposta piuttosto generale. Tradizionalmente, la vista in MVC richiede le informazioni di cui ha bisogno dal modello e il modello non sa nulla della vista. Il binding dei dati (molto diffuso nelle interfacce utente Microsoft) lega la visualizzazione abbastanza strettamente al modello sottostante, che è in conflitto con il tradizionale MVC.

Quindi la soluzione è di avere un modello per la vista da associare e un modello diverso che è realmente il Modello. Questi sono il modello di vista e il modello di dominio.

Alle tue domande: la relazione tra loro è che la VM conosce il DM, non viceversa, e la VM ha in sé cose extra specifiche per la Vista da usare. Se non hai una visualizzazione con questi requisiti, non hai affatto bisogno di un modello di visualizzazione.

In quei casi in cui è necessaria una VM, consiglierei di pensarla come un wrapper sul DM. La VM avrà proprietà uniche da visualizzare e delegherà richieste e aggiornamenti ai dati aziendali al DM. Non ci dovrebbe essere alcuna duplicazione della logica tra di loro.

Quando l'ho usato nelle app WPF o Store, la VM è il contesto di associazione dei dati per la vista, nelle immediate vicinanze, e il DM accede attraverso un'interfaccia formale, probabilmente lontana.

Non ho idea se esiste un modello per questo - la mia mente non funziona in questo modo.