Chiarimento MVVM

Stiamo per scrivere la nostra prima applicazione WPF e stiamo acquisendo familiarità con il modello MVVM. Abbiamo creato molte applicazioni Winform e disponiamo di un'architettura che ha riscosso molto successo per noi. Stiamo riscontrando un po 'di problemi nel tradurre quell'architettura o nel determinare la posizione di alcuni elementi della nostra architettura nel modello MVVM.

Storicamente abbiamo una Gui (exe principale) che comunica poi con una dll BusinessLogic. BusinessLogic comunica a una DLL DAL tramite un servizio Web e la DAL interagisce con il DB. DAL, BusinessLogic e GUI fanno tutti riferimento alla stessa dll BusinessObjects.

Parte del passaggio a MVVM è piuttosto semplice. La nostra Gui conterrà comunque le viste, i nostri BusinessOjbects conterranno comunque il modello e il nostro DAL interagirà comunque con il DB (sebbene la tecnologia per implementarli possa cambiare).

Ciò di cui non siamo sicuri è il nostro componente BusinessLogic. Storicamente ciò fornirebbe funzioni che la GUI può chiamare per poi popolare i controlli nelle viste (es. GetCustomerList che restituirebbe un elenco di oggetti Customer o le tipiche funzioni CRUD).

Il problema principale che abbiamo è se il modello MVVM richiederebbe un componente aggiuntivo per ospitare i ViewModels o se cambiassimo il nostro modo di pensare e migrassimo ciò che abbiamo usato come nostro componente BusinessLogic nei ViewModels?

Il nostro componente BusinessLogic rappresenta i ViewModels?

In generale, non posizionerei la logica aziendale nel livello del modello di visualizzazione. Ma il termine "Business Logic" è fuorviante.

Eric Evans utilizza un modello in cui la logica aziendale è divisa in due categorie

• Logica di dominio - Logica correlata al dominio del problema effettivo che si sta risolvendo
• Logica dell'applicazione: logica correlata al fatto che si sta creando un'applicazione

Cita l'esempio di un'applicazione contabile. Le regole relative a conti, post, conti fiscali, ecc. Sono regole di dominio, regole relative al dominio della contabilità. La logica dell'importazione / esportazione CSV non ha nulla a che fare con il dominio della contabilità. Queste regole esistono solo perché stiamo costruendo un'applicazione software. Questi sono esempi di logica dell'applicazione.

Le regole di dominio non devono MAI andare nel livello del modello di visualizzazione. Se stai seguendo il modello MVVM, le regole del dominio vanno, senza dubbio, nel livello del modello.

Le regole dell'applicazione, come l'importazione / esportazione CSV, potrebbero andare nel livello del modello di visualizzazione. Ma personalmente, preferirei separarlo in un livello logico di applicazione separato.

Il modello di visualizzazione dovrebbe essere molto semplice. Cercare i dati necessari alla vista nel modello corrispondente, aggiornare il modello quando la vista cambia, ascoltare gli eventi nel modello e propagare quegli eventi alla vista, consentendo di aggiornare la vista quando il modello viene aggiornato dietro le quinte (se applicabile).

Personalmente mi assicurerei che il livello del modello di vista contenga solo un tipo di logica, la logica di presentazione.

Sì.

Il livello di logica aziendale è rappresentato dal livello VM. Quindi basta migrare il tuo modello mentale.

Per facilitare la migrazione del modello mentale, una leggera sfumatura è che gli oggetti GUI (View) dovrebbero essere associati agli oggetti all'interno del livello VM. Tale associazione si traduce in | implica che la vista non sia più il livello che "effettua la chiamata" per recuperare qualcos'altro. La chiamata per il recupero dei dati verrà invece dalla VM.

Per spiegare meglio: Sì, un oggetto all'interno della Vista dovrà cambiare per innescare la sequenza di cose che effettueranno la chiamata. Ma View non effettua la chiamata stessa. E in questo caso, considero un clic sul pulsante equivalente a qualcosa all'interno della vista che cambia, ma che comunque non effettua la chiamata.

Nel primo caso, l'oggetto View verrà associato a un oggetto VM. La VM dovrebbe essere in attesa di un evento di modifica della proprietà sull'oggetto associato. L'evento di cambio oggetto può quindi essere collegato a una funzione VM per effettuare la chiamata del modello.

Nel secondo caso (evento clic pulsante), l'evento modifica (clic) può essere collegato a una chiamata di funzione esposta dalla VM.

Ad ogni modo, è sempre un evento che viene sequenziato nella VM e che quindi chiama il Modello che a sua volta chiama DAL / DB.

Lo faccio apparire perché un po 'di codice WinForm viene utilizzato per effettuare una chiamata al livello DB direttamente dal code-behind della GUI di WinForm. Tale approccio interrompe la separazione fornita da MVVM.

Hai ragione a dire che in sostanza sostituiresti la tua dll BusinessLogic con il tuo livello ViewModel, tuttavia penso che la differenza più grande che dovrai affrontare sia il modo in cui il livello View / UI interagisce con il tuo livello ViewModel / BusinessLogic.

In WinForms, la GUI è la tua applicazione ed è responsabile del flusso dell'applicazione. In WPF / MVVM, ViewModels è la tua applicazione e la GUI diventa solo un'interfaccia intuitiva per interagire con ViewModels.

Ad esempio, con WinForms, potresti avere un DataGrid e un pulsante e quando fai clic su quel pulsante, chiami BusinessLogicLayer.GetProducts()e carichi gli oggetti prodotto risultanti in DataGrid.

Con WPF, avresti un ViewModel che contiene an ObservableCollection<Products>e an ICommand GetProductsed eseguendo il comando chiama DAL e carica la raccolta di prodotti. Ma per fornire un'interfaccia intuitiva per questo, è necessario creare una vista che esegua il rendering di ViewModel utilizzando un DataGrid per la raccolta Prodotti e un pulsante per il comando GetProducts.

In realtà ho scritto un post abbastanza recente per il mio blog sul cambiamento di mentalità quando si passa da Winforms a WPF sul mio blog e penso che il modo migliore per riassumere la differenza sia con queste immagini: