Duplicazione del modello di dominio in Visualizza modello o no

Question

Duplicazione del modello di dominio in Visualizza modello o no

#1 da (1 voti)

0

Ho un file XML che contiene informazioni di configurazione per un sistema. Posso serializzare / deserializzare l'XML in una gerarchia di oggetti che descrivono la configurazione (e non più) e quindi passare quegli oggetti a un'attività che esegue il lavoro in base ai dati negli oggetti.

Quello che voglio fare è costruire un editor specializzato per il mio XML per consentire a un utente di costruire il file di configurazione tramite punta e clicca anziché aprirlo in un editor di testo e modificare manualmente le cose. L'idea è di fornire coerenza e controllo degli errori quando vengono immesse le informazioni di configurazione (al contrario del sistema di run time che dice FU e di dover capire cosa hai sbagliato). A causa della normalizzazione dei dati nell'XML ci sarebbe quasi una corrispondenza 1: 1 di elementi / attributi XML ai campi di modifica dell'utente sullo schermo.

Tuttavia, quando penso a questo in termini MVVM, sembra che abbia due scelte, nessuna delle quali mi piace.

Una gerarchia del modello di vista separata duplica tutti i campi nel modello XML aggiungendo il controllo degli errori e tutto il resto necessario (come associazione di dati e aggiornamenti delle proprietà ecc.) per accoppiare un modello di vista a una vista in WPF utilizzando MVVM .
Il modello XML assorbe tutto ciò che farebbe un modello di vista separato, ma finisco per avere una singola (sebbene orrenda) gerarchia di oggetti coerenti.

Quindi sembra che io duplichi la gerarchia, crei problemi di coerenza, o violi avere una vista separata e modelli di dominio e crei una grande palla di codice.

C'è un altro modo in cui posso strutturare il mio editor che evita questi due progetti e le loro insidie?

Questa domanda del 2012 ha chiesto che cosa potrebbe sembrare un duplicato , ma le risposte sono incoerenti a dir poco.

architecture domain-model wpf mvvm

posta Peter M 18.10.2017 - 21:20

fonte

1 risposta

Leggi altre domande sui tag architecture domain-model wpf mvvm

Verifica delle autorizzazioni con più chiamate al database o in stored procedure? Integrità del sito Web implementato

score 1 · Answer 1

MVVM tende a diventare un po 'goffo quando l'applicazione è diretta (come la mappatura 1-1 dei campi menzionati). I vantaggi derivano da app di relativa complessità e dimensioni medie e grandi.

Quindi, se il tuo editor è una semplice applicazione, potrebbe essere meglio evitare (o utilizzare un design MVVM leggero come nella tua opzione 2) tutta la cerimonia che accompagna MVVM.

Per quanto riguarda l'opzione 1, non sono davvero d'accordo sul fatto che ViewModel sarà semplicemente un "gateway" puro tra la View e il parser XML. Si menziona la convalida dell'errore, ecc., Che sono tutte attività principalmente adatte a ViewModel. Penso che quando inizi a scrivere l'editor, vedrai molto rapidamente la maggior parte delle funzioni più adatte nel ViewModel piuttosto che in una qualsiasi delle altre parti.

C'è anche un altro punto qui. Stai scrivendo un editor XML oggi, ma più tardi ti renderai conto che la GUI che hai costruito si adatta molto bene ad un'altra applicazione o che un nuovo tipo di file è stato inventato in futuro e vuoi usarlo con il tuo editor. Se non segui uno schema di progettazione come MVVM, potresti essere limitato alla quantità di app che puoi utilizzare.

Infine, non penso che l'opzione 2 sia un buon progetto MVVM. Il tuo modello non dovrebbe fare ciò che fa il ViewModel e viceversa. Il parser XML è il tuo modello e ViewModel esegue tutte le modifiche / conversioni e la manipolazione dei dati necessarie affinché la Vista sia in grado di presentarla. Consideralo come uno spazio tra il modello e la vista in cui puoi "giocare" con i dati prima che vengano presentati o che vengano trasmessi al modello.

C'è anche un altro vantaggio che ha una via di mezzo. Un ViewModel può collegarsi a più di un modello. Ad esempio, è possibile avere il parser XML e un altro più efficiente e consentire agli utenti di selezionare quale utilizzare. Nell'opzione 2, ci si ritroverà con un modello enorme (che violerà un paio di principi SOLID). Se hai un ViewModel, entrambi i modelli possono essere collegati ad esso e utilizzati di conseguenza dandoti un codice più pulito.