Elenchi e raccolte in MVVM: quale approccio adottare?

Sì, entrambi i modi sono validi. Ci sono pro e contro per ogni approccio.

Se Person può essere visualizzato in diversi modi a seconda del contesto - se è in ListBox o su una "pagina", usa la tua tecnica con ItemTemplate per controllare come viene visualizzato nell'elenco è probabilmente il modo migliore per andare.

Penso che tu debba guardare al tuo progetto generale e vedere quale si adatta meglio. Cambiare l'implementazione in parte è una cattiva idea. Alcune "pagine" saranno il vecchio stile e altre saranno le novità, portando a incongruenze nell'esperienza utente e potenzialmente maggiori sforzi nel mantenimento e nell'estensione del sistema. Se non altro, dovrai passare attraverso il codice esistente per renderlo conforme al nuovo formato.

Ok, supponendo che Person sia la tua entità (oggetto del modello) ...

Puoi farlo in entrambi i modi, ma con qualche avvertenza:

1) Il collegamento diretto a un oggetto modello funziona bene in schermate di sola lettura. Se si restituisce solo un elenco di People e si desidera che l'utente ne scelga uno, ottimo, è facile collegarsi a tale elenco.

2) Il binding diretto al tuo modello di dominio può iniziare a succhiare se stai implementando uno schermo che ti permetta di manipolare quegli oggetti. Lo stato dei dati in modifica può rappresentare uno stato di modello non valido fino a quando non viene convalidato e salvato .

A causa del # 2, molte persone creano un PersonViewModel che è davvero per il montaggio. Non penso che sia una buona idea neanche. Penso che sia necessario definire le classi di modelli che rappresentano lo stato durante la modifica (e le operazioni di mappatura tra le classi Person e PersonEdit , inclusa la convalida).

Ora se vuoi aggiungere un PersonViewModel , ha alcuni vantaggi. Diciamo che il tuo Person ha una proprietà DateOfBirth e una proprietà derivata Age , e un'altra proprietà derivata AgeGroup (forse Toddler, Preteen, Teen, ecc.). Cosa succede se si desidera visualizzare quelle persone evidenziate colori diversi in base alla loro fascia di età? Puoi definire un ValueConverter (se vuoi ancora associare direttamente all'oggetto Person ), oppure puoi avvolgere l'oggetto Person in PersonViewModel e aggiungere una proprietà AgeGroupColor al modello di vista. Quindi puoi legare direttamente a quello. Il metodo che scegli dipende proprio da te. A molte persone non piace ValueConverters , e sono d'accordo che sono un po 'prolissi per quello che fanno, quindi probabilmente andrei con l'opzione modello di visualizzazione, come il tuo amico.

Non ha senso avere PersonViewModel se non ha proprietà aggiuntive al di sopra del modello Person . È solo una perdita di tempo.

Tuttavia, se utilizzi convertitori di valori per convertire un Person in qualsiasi modo, avrei utilizzato PersonViewModel e non mi sono preoccupato del convertitore di valori.

PersonViewModel dovrebbe semplicemente esporre l'oggetto Person e eventuali proprietà aggiuntive. Non potrei proxy ogni singola proprietà Person in PersonViewModel .

Se una persona è nel tuo modello, sembra violare la separazione creata solo esponendo il modello di vista alla vista.

La mia regola generale è la possibilità di creare il viewmodel e visualizzare senza un modello. Se questo non può essere realizzato, apporto delle modifiche.

L'esposizione del modello alla vista è perfettamente valida, ma è più di un pattern MVC.