MVVM Chiarimento

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

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

• Logica del dominio - Logica relativa al dominio del problema che stai risolvendo
• Logica dell'applicazione - Logica relativa al fatto che stai costruendo un'applicazione

Egli menziona l'esempio di un'applicazione di contabilità. Le regole su account, post, conti fiscali, ecc. Sono regole di dominio, regole relative al dominio della contabilità. La logica relativa all'importazione / esportazione CSV non ha nulla a che fare con il dominio della contabilità. Queste regole esistono puramente perché stiamo costruendo un'applicazione software. Questi sono esempi di logica applicativa.

Le regole di dominio non dovrebbero MAI entrare nel livello del modello di vista. Se stai seguendo lo schema MVVM, le regole del dominio vanno, senza dubbio, nel livello del modello.

Le regole delle applicazioni, come l'importazione / esportazione CSV, potrebbero andare nel livello del modello di vista. Ma personalmente, preferirei separarlo in un livello logico applicativo separato.

Il modello di vista dovrebbe essere molto semplice. Ricerca dei dati necessari per la vista nel modello corrispondente, aggiornamento del modello quando la vista cambia, ascolto degli eventi nel modello e propagazione di tali eventi alla vista, che consente di aggiornare la vista quando il modello viene aggiornato dietro le quinte (se applicabile).

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

Sì.

Il livello della logica aziendale è rappresentato dal livello VM. Quindi migri semplicemente il tuo modello mentale.

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

Per spiegare meglio: Sì, un oggetto all'interno della vista dovrà essere modificato per attivare la sequenza di cose che effettueranno la chiamata. Ma la vista non rende la chiamata stessa. E in questo caso, considero un clic del pulsante come equivalente a qualcosa all'interno della vista che cambia, ma che ancora non effettua la chiamata.

Nel primo caso, quell'oggetto View sarà associato a un oggetto VM. La VM dovrebbe essere in ascolto di un evento modificato proprietà sull'oggetto associato. L'evento di modifica dell'oggetto può quindi essere collegato a una funzione VM per effettuare la chiamata Modello.

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

In ogni caso, è sempre un evento che esegue sequenze nella VM che chiama quindi il modello che a sua volta chiama il DAL / DB.

Ne parlo perché un codice WinForm è usato per effettuare una chiamata al livello DB direttamente dal code-behind della GUI di WinForm. Questo approccio rompe la separazione che MVVM sta fornendo.

Hai ragione a sostituire essenzialmente la tua DLL di BusinessLogic con il tuo layer ViewModel, tuttavia ritengo che la differenza più grande che dovrai affrontare sia il modo in cui il livello View / UI interagisce con il tuo layer ViewModel / BusinessLogic.

In WinForms, la GUI è la tua applicazione ed è responsabile del flusso di applicazioni. In WPF / MVVM, i tuoi ViewModels sono l'applicazione e la GUI diventa un'interfaccia intuitiva per interagire con ViewModels.

Ad esempio, con WinForms, potresti avere un DataGrid e un Button, 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 ObservableCollection<Products> e ICommand GetProducts , e l'esecuzione del comando chiama il DAL e carica la raccolta di prodotti. Ma per fornire un'interfaccia user-friendly, dovresti creare una View che renderizza ViewModel usando un DataGrid per la collezione Products e un Button per il comando GetProducts.

In realtà ho scritto un post abbastanza recente per il mio blog su il cambiamento in 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: