Qual è il modo migliore per condividere dati specifici tra ViewModels

2

Abbiamo IAppContext che viene iniettato in ViewModel.
Questo servizio contiene dati condivisi: filtri globali e altre proprietà a livello di applicazione.

Ma ci sono casi in cui i dati sono molto specifici. Ad esempio, una VM implementa il master e il secondo - i dettagli dell'oggetto selezionato. Quindi DetailsVm deve conoscere l'elemento selezionato e le sue modifiche.

Possiamo memorizzare queste informazioni in IAppContext o all'interno di ciascuna VM interessata. In entrambi i casi le notifiche di aggiornamento vengono inviate tramite Messenger.

Vedo pro e contro per qualsiasi approccio e non riesco a decidere quale sia il migliore.

1 °:
+ proerties condivise esplicitamente esposte, dipendenze facili da seguire - IAppContxt diventa ingombro di dati molto specifici.

2 °:
l'esatto opposto del primo e più carico di memoria dovuto alla duplicazione dei dati.

Qualcuno potrebbe offrire alternative di progettazione o dire che una delle varianti è oggettivamente superiore all'altra causa mi manca qualcosa di importante?

    
posta Pavel Voronin 03.12.2012 - 14:01
fonte

1 risposta

1

Spero che questa risposta sia di beneficio per gli altri che raggiungono tale domanda, perché solo con il timestamp penso che OP abbia risolto il problema molto tempo fa. ;-) Il post non presenta una soluzione immediata (avrei bisogno di più dati da OP per quello), ma offre invece alcuni suggerimenti.

padre-figlio

Come menzionato nei commenti (prima da @Rachel), per i dati gerarchici esiste una relazione genitore-figlio.

Principio di incertezza

Come per qualsiasi decisione di design, c'è il principio di indeterminazione : tieni a bada il più a lungo possibile. Implementa entrambi e fai in modo che vadano avanti e vedi quali sono i tuoi casi migliori. Dovrei notare che non sono affatto esperto in WPF, ma quella frase:

I see pros and cons for any of the approaches and can not decide which one is better.

indica strongmente il rifiuto di una decisione finché non vedi che un approccio produce risultati migliori di quelli che funzionano per te.

Dipende

Dato che ci sono poche informazioni su casi d'uso e quantità di dati condivisi / specifici, proporrò alcune cose basate su ipotesi.

Supponendo dati extra molto diversi, sempre specifici del caso

  1. Per ogni caso, crea un file di proprietà o oggetti valore in grado di memorizzare dati aggiuntivi.
  2. Aggiungi meccanismo che consente ad AppContext di richiamare detto file di proprietà / oggetto valore in nome / id / altro.
  3. Le macchine virtuali che richiedono questo dovrebbero essere in grado di dire a AppContext di estrarre quei dati quando vengono inizializzati. Questo può anche essere fatto tramite la convenzione di denominazione.

Supponendo dati extra molto diversi, parzialmente riusabili

Procedi come in caso precedente. Perché nonostante questo consiglio, sto segnalandolo come una sezione separata? Perché nei casi di riutilizzo solo parziale, spesso mi sembra prudente saltare semplicemente il riutilizzo:

  1. il riutilizzo parziale si tenta, ma raramente vale davvero il tempo speso per pensare "come riutilizzarlo bene"
  2. se si compromette il riutilizzo, il risultato finale è raramente gestibile
  3. i neofiti che arrivano al codice saranno piuttosto confusi quando DOVREBBERO riutilizzare e quando no e COME riutilizzare

Conclusione: la chiarezza soffre. Se non sei sicuro che i dati verranno riutilizzati, non preoccuparti.

Supponendo una grande quantità di dati extra, molti casi diversi, riutilizzo significativo

Dividi l'app. Ovviamente ci sono troppe app che cercano di adattarsi qui ei pattern identificati potrebbero essere domini diversi. A questo punto ho dato uno sguardo più da vicino ai pattern DDD (specialmente Bounded Context) e prenderemo in considerazione il trasferimento dei dati condivisi reali da IAppContext al dominio di supporto.

    
risposta data 09.05.2014 - 18:09
fonte

Leggi altre domande sui tag