Guida WPF, MVVM, EF, POCO necessaria su architettura semplice

Question

Guida WPF, MVVM, EF, POCO necessaria su architettura semplice

#1 da (7 voti)

6

(scusate il mio povero inglese) Sto sviluppando un'applicazione che usa WPF, codice EF prima usando MVVM (Caliburn.Micro). Dovrebbe essere usato principalmente per il lavoro CRUD. Ho creato una classe BaseViewModel<T> da cui tutti gli altri ViewModels ereditano ed espongono una proprietà T Selected per collegarsi alla vista. So che non è consigliato esporre un modello alla vista, ma rende le cose semplici per far funzionare l'app.

Il problema è che non voglio inquinare i miei modelli (classi EF POCO) con INotifyPropertyChanged , IDataErrorInfo , IEditableObject , ecc ... Quindi, c'è qualcosa che posso fare qui o devo fare duplica davvero tutte le proprietà del modello su ViewModel e rinuncia a provare a legare direttamente il modello? Vorrei usare anche la validazione degli attributi, poiché tutti i modelli li hanno già.

Ho usato questo approccio in passato con Silverlight / RIA ma in questo caso i Servizi RIA hanno generato le classi per me, con tutto il codice dell'impianto idraulico.

Posso ottenere gli errori di validazione usando la classe Validator ma devo anche indicare il componente che ha l'errore no l'interfaccia utente e penso di aver bisogno di implementare IDataErrorInfo sul mio modello affinché questo accada, giusto?

Per INotifyPropertyChanged Posso usare qualcosa come NotifyPropertyWeaver ma il mio problema è IEditableObject e qualcosa per poter usare la convalida dell'attributo. Sarebbe bello qualcosa come MagicBusinessBaseClassThatImplementAllThoseInterfaces<Model> per incapsulare il modello in modo che io possa legarlo e andare avanti.

So che posso fare questo lavoro implementando manualmente le interfacce su ogni VM - ma basti pensare a tutto il codice "duplicato" che mi fa rabbrividire :(

In che modo gli sviluppatori WPF stanno facendo questo genere di cose oggi? C'è qualche tecnica di ninja segreta di cui non sono a conoscenza?

architecture wpf mvvm

posta user1576950 09.08.2012 - 17:46

fonte

1 risposta

Leggi altre domande sui tag architecture wpf mvvm

Come gestire / organizzare quando devi eseguire più task su più progetti 1 man? [chiuso] Procedura guidata licenze software

score 7 · Accepted Answer

Personalmente non vedo nulla di sbagliato nell'associare direttamente a Model invece di esporre le proprietà attraverso ViewModel , tuttavia se prevedi di legare alle tue classi EF POCO, devi averle implementare INotifyPropertyChanged in modo che l'interfaccia utente sa quando si aggiornano.

EF dovrebbe avere un'impostazione che farà sì che generi le classi con INotifyPropertyChanged già implementate, tuttavia dovrai comunque fare qualcosa di personalizzato per ottenere IDataErrorInfo per funzionare nel modo desiderato (ti consiglio di usare IDataErrorInfo invece della classe Validator quando si lavora con WPF perché XAML è già configurato per utilizzare quell'interfaccia per errori). Generalmente creo classi parziali per ogni modello di dati che richiede la convalida che implementa IDataErrorInfo , anche se so che esistono altri metodi che potrebbero funzionare meglio per te.

Un'altra alternativa che ho usato in passato è quella di creare un altro livello interamente per i modelli, e non utilizzare modelli EF su tutti gli altri che nel livello del database. Penso che l'ultima volta che l'ho fatto, ho modificato il template T4 di EF per autogenerare i miei modelli nello stesso momento in cui sono stati generati gli oggetti EF POCO, con la stessa struttura dati esatta, e ho usato AutoMapper per mappare gli oggetti EF agli oggetti del mio modello ogni volta che è stata effettuata una chiamata al database.

E, naturalmente, c'è anche la terza alternativa che hai menzionato di esporre semplicemente le proprietà da ViewModel e non vincolare affatto a Model . Questo è il modo "MVVM-Purist" di farlo, ma spesso non è così pratico poiché richiede più tempo per l'implementazione.