Il presente articolo è stato tradotto automaticamente.

Modello di progettazione MVPVM

Il modello di progettazione MVPVM (Model-View-Presenter-ViewModel) per WPF

Bill Kratochvil

Scaricare il codice di esempio

Di tutto il successo projectsI hai fatto parte di, quelli di maggior successo condividevano un risultato comune: L'applicazione si ingrandirono, il codebase divenne più piccolo. Sulla superficie, questo può sembrare contraddittorio, ma la codifica in un ambiente flessibile si presta a una contrazione codebase. Come requisiti cambiano, refactoring si verifica e questa opportunità refactoring — accoppiato con il senno di poi — fornisce la possibilità di riutilizzare componenti esistenti in modo più efficiente, eliminando i duplicati codice nel processo.

Al contrario, ci sono stati alcuni progetti monolitici, che a volte sono stati ritenuti di successo, dove il codice sorgente è cresciuto ed è cresciuta con poche opportunità per il riutilizzo. Questi progetti divennero risorse e un rischio per la crescita futura. Qual è stata la differenza fondamentale? Il modello di progettazione infrastrutturale utilizzato. I modelli che si utilizza determinerà se dipingere te stesso in un angolo o tenere la schiena alle opportunità aperto che il futuro potrebbe portare.

In questo articolo, ti presento un tale modello — trascurato da molti sviluppatori di Windows Presentation Foundation (WPF) a causa della popolarità del pattern Model-View-ViewModel (MVVM) — chiamato il pattern Model-View-Presenter-ViewModel (MVPVM). Questo modello di progettazione di applicazione enterprise è stata introdotta in Microsoft patterns & le pratiche di progetto Prism (Prism.CodePlex.com). (Nota: Questo modello era senza nome, quindi mi riferisco ad esso come MVPVM.) Prisma è meglio descritta con un brano dal suo sito Web panoramica:

"Prisma fornisce orientamento progettato per aiutarvi a più facilmente progettare e costruire ricco, flessibile e facile da mantenere applicazioni desktop Windows Presentation Foundation (WPF), Silverlight Rich Internet Applications (RIA) e applicazioni di Windows Phone 7. Utilizzo di modelli di progettazione che incarnano i principi di progettazione architettonica importante, come la separazione delle preoccupazioni e accoppiamento lasco, prisma vi aiuta a progettare e costruire l'applicazione­cationi utilizzando vagamente accoppiato componenti che possono evolvere in modo indipendente, ma che può essere facilmente e perfettamente integrato nell'applicazione generale. Questi tipi di applicazioni sono conosciuti come le applicazioni composite."

La popolarità e il successo di MVVM oscura la MVPVM anche se MVPVM è l'evoluzione del MVVM (come dimostrerà questo articolo). MVPVM offre tutta la potenza e la capacità di MVVM introducendo la scalabilità e l'estensibilità del modello Model-View-Presenter (MVP). Se la vostra comprensione è che MVVM si è evoluto da MVP per WPF, allora troverete questo articolo illuminante.

Prima che possiamo apprezzare pienamente il potere e i vantaggi di MVPVM, dobbiamo capire come questo modello evoluto — dobbiamo capire la nostra storia. Il pattern Model-View-Controller (MVC) è una componente cruciale al raggiungimento di questa comprensione, così I'll primo introdurre MVC, forse in modo che non abbiate mai visto prima.

Il modello MVC

Si prega di notare che questa discussione MVC è nel contesto delle applicazioni desktop; Le applicazioni Web sono un'altra storia e lo scopo di questo articolo.

Nel documento "GUI architetture" Martin Fowler (bit.ly/11OH7Y), egli afferma quanto segue su MVC: "Persone diverse leggendo su MVC in luoghi diversi prendere idee diverse da esso e descrivere questi come 'MVC.' Se questo non causa abbastanza confusione, è quindi ottenere l'effetto di fraintendimenti di MVC che si sviluppano attraverso un sistema di sussurri cinesi." Il "Whatsa Controller comunque" documento a bit.ly/7ajVeS somme su suo punto piacevolmente affermando: "Gli scienziati informatici hanno in generale una fastidiosa tendenza a termini di sovraccarico. Vale a dire, essi tendono a assegnare più di un significato (a volte contraddittorio) per la stessa parola."

Smalltalk MVC ottiene ulteriormente complicata dal fatto che gli sviluppatori di mancano di una base comune esperienza con loro grandi architetti in materia di ambiente architetto. Come tale, il sovraccarico di termini e "Chinese whispers" sono involuta ancor più dal fatto che la maggior parte di noi non sanno nemmeno che cosa un Controller è perché mai abbiamo dovuto utilizzare uno — OS ha sempre gestito la sua funzionalità per noi. Con alcuni fatti a fornire la base comune di esperienza che ci manca, troverete MVC è realmente facile da capire, e che la "C" di MVC non ha nulla in comune con la "P" in MVP.

Il Controller hanno un'origine calcestruzzo (che vale la pena di comprensione, ma non necessariamente corrisponde moderni approcci a MVC nel contesto delle attuali tecnologie). Il padre fondatore del MVC, Trygve Reenskaug, scritto su che nel 1979 nel suo documento sulla "Controller di visualizzazioni modelli" (bit.ly/2cdqiu). Questo documento inizia a fornire alcune informazioni sullo scopo del Controller. Reenskaug ha scritto:

"Il legame tra un utente e il sistema è un controllore. Fornisce l'utente con input disponendone pertinenti visualizzazioni di presentarsi in luoghi appropriati sullo schermo. Fornisce mezzi per output utente presentando l'utente con menu o altri mezzi di dare comandi e dati. Il controller riceve tale output utente, si traduce in un messaggio appropriato e passa questi messaggi a uno o più dei punti di vista.

Un controller mai dovrebbe integrare le opinioni, non dovrebbero per esempio mai collegare le opinioni dei nodi disegnando frecce tra di loro.

Al contrario, una vista mai dovrebbe conoscere l'input dell'utente, quali le operazioni del mouse e combinazioni di tasti. Dovrebbe sempre essere possibile scrivere un metodo in un controller che invia messaggi a vista, che riproducono esattamente qualsiasi sequenza di comandi utente."

Questo concetto è illustrato nel Figura 1.

Un "messaggio," nel contesto di MVC orientati agli oggetti (OOP), di programmazione è un mezzo per l'esecuzione di metodi. Essi sono stati descritti come "messaggi", perché allora, chiamate virtuale erano un nuovo concetto ed è stato un modo per distinguerli dalle chiamate di funzione statica. Nel capitolo 1.2 del libro "Smalltalk, an Introduction to Application Development Using VisualWorks" (Prentice Hall, 1995), Trevor Hopkins e Bernard Horan, gli autori noti "… se l'oggetto ricevente capisce il messaggio è stato inviato, quindi verrà eseguita una delle sue operazioni interne (o metodi). Ciò, a sua volta, può causare alcuni calcoli di prendere posto (agendo su una o più delle variabili interne dell'oggetto)." (Nota: Questo concetto OOP "l'invio dei messaggi" è disponibile in Prisma tramite suo EventAggregator.)

Il libro delinea piacevolmente le responsabilità del MVC Smalltalk nel capitolo 29, "Introduzione ai modelli, visualizzazioni e controllori," da insegnarci che controller derivano dalla classe Controller. Si afferma, "Le istanze di questa classe hanno un riferimento a un sensore che rappresenta il mouse e la tastiera, affinché sia possibile elaborare input". Continua a dirci che le due azioni distinte avviate da un Controller sono comunicazioni con il modello (vedere Figura 1) e le comunicazioni con la vista senza intaccare il modello.

Figura 1 Controller riceve Input e Invia messaggio (metodo da eseguire); Visualizzazioni non possono intercettare l'Input dell'utente

In Smalltalk MVC, "ogni" vista avrà un Controller e un solo Controller in un determinato momento può essere attivo. In originale MVC di Smalltalk, l'interfaccia utente è stata polling; la classe ControlManager primo livello ciascuno dei controllori della visualizzazione attiva chiede se vuole controllo. Solo la vista che contiene il cursore può accettare il controllo. Se una vista è in sola lettura, c'è una classe NoController disponibile che è progettato per rifiutare il controllo. Una vista con sottoviste ha la responsabilità di sondaggio i controllori della sua secondarie. Una volta un Controller ha accettato di controllo, esso sarà interrogare i risultati della tastiera o del mouse e inviare messaggi alla visualizzazione o modello applicabile, come il movimento del mouse, clic del pulsante e così via. In termini MVVM, questo sarebbe paragonabile a sottoscrivere gli eventi di un controllo in entrambi codebehind della visualizzazione o tramite un comando ViewModel. Quando un utente interagisce con il controllo, si chiamerà il metodo applicabile.

A questo punto, è possibile iniziare a sbirciare dietro lo scopo del controllore all'interno del contesto di MVC e un ambiente che non gestione eventi automaticamente per voi. A differenza di sviluppatori Smalltalk MVC, gli sviluppatori WPF non hanno eseguire query pacchetto e tastiera buffer e generare eventi. È semplicemente iscriversi a loro e al metodo applicabile "automagicamente" li riceve tramite il modello di evento di Microsoft. Con questa conoscenza, di seguito forse avrà un significato diverso e meno confuso.

Nell'articolo di Steve Burbeck, "applicazioni di programmazione Smalltalk-80: Come a uso Model-View-Controller (MVC) "(bit.ly/3ZfFCX), egli afferma quanto segue:

"Il controller interpreta gli input del mouse e la tastiera da parte dell'utente, comandando il modello e/o la visualizzazione di cambiare come appropriato. Infine, il modello gestisce il comportamento e i dati del dominio applicazione, risponde alle richieste di informazioni sul suo stato (di solito dalla vista) e risponde alle istruzioni per modificare lo stato (di solito dal controllore)."

Vedere Figura 2 per un'illustrazione di questo concetto.

Figura 2 Smalltalk Model-View-Controller

Un punto finale per portare chiarezza a che cosa potrebbe essere un argomento fangoso è nel documento, "Torcendo la triade, l'evoluzione del quadro Dolphin Smalltalk MVP applicazione," da Andy Bower e Blair McGlashan a bit.ly/o8tDTQ (Scarica PDF). Questo è uno dei documenti più completi che ho letto sul tema. Gli autori notare quanto segue circa il Controller: "Le opinioni, naturalmente, sono responsabile per la visualizzazione dei dati del dominio, mentre i controller gestire i gesti di utente crudo che alla fine si esibiranno azioni su tali dati."

Portare questo punto finale così che ho l'opportunità di fornire un'altra definizione. Per comprendere appieno l'articolo (e altri su MVC), dovete capire che cosa significa "gesti" (vedere Figura 1). Nella mia ricerca mi sono imbattuto in questo articolo, "An introduzione a GUI di programmazione con UIL e Motif" (bit.ly/pkzmgc), che afferma quanto segue:

"L'essenza di questi passaggi è che un programma Motif non fa nulla fino a quando l'utente richiede qualche azione. Le azioni vengono richiesti selezionando una voce di menu, facendo clic su un pulsante o altra finestra o premendo un tasto. Queste, collettivamente, sono gesti di utente. Ogni gesto si innescherà una funzione di applicazione per eseguire alcuni compiti."

Andy Bower, coautore di "Torcendo la triade" condiviso il suo pensiero su "gesti" con me:

"Il mio prendere su 'gesti' è che sono una coalescenza di uno o più eventi utente in qualcosa di più significativo.

Ad esempio un TextController potrebbe assorbire il tasto giù e chiave gli eventi e li converte in gesti individuali 'keypress'. Analogamente, un SelectionInListController (il Controller collegato a una casella di riepilogo) potrebbe assorbire diversi eventi del mouse-down, rilevamento del mouse e del mouse-up all'interno di un elenco e li trattano come un gesto di 'selezione' lista unica.

Guardò come questo, vediamo che un moderno OS basato sugli eventi già fa la maggior parte di questo gesto di elaborazione per noi."

Per riassumere la logica Controller, si vede che la funzione di Controller è piuttosto coerenza tra le variazioni di MVC a cui fa riferimento. Poiché i controlli Microsoft (widget) gestiscono "gli input del mouse e la tastiera da parte dell'utente", semplicemente sottoscrivere gli eventi e scegliere il metodo che deve essere eseguito — "Controller" all'interno di controlli intelligenti esegue il metodo per te (gestiti a livello di OS). Come tale, non avete bisogno di un Controller, come chiaramente indicato dall'articolo "Torcendo la triade". Senza il Controller, sei lasciato con il pattern Model-View per le applicazioni Windows. Devi tenere questo in mente come si studia MVC e la sua applicazione e presentazione modelli perché senza il Controller, non non c'è nessun triade (vedere Figura 3).

Figura 3 senza Controller, esso è stato Model-View (non Model-View-Controller)

Vale la pena ricordare che non era solo il Controller che ha causato l'ambiguità con MVC. Con MVC Smalltalk, la logica di dominio/business è nel modello, e con VisualWorks MVC il ApplicationModel contiene la logica di "applicazione" necessaria per presenti uno o più oggetti di dominio/business per l'utente (vedere Figura 4). L'articolo "Torcendo la triade" questo copre in modo più dettagliato. Se si considera che il modello di applicazione e il modello di presentazione hanno le stesse funzionalità, con la netta differenza è che il modello di presentazione "Impossibile" accedere la vista (Martin Fowler fatta una netta distinzione per non sovraccaricare i termini), poi gli sviluppatori WPF possono cogliere rapidamente modello di presentazione, perché si tratta in sostanza di MVVM. John Gossman, padre fondatore della MVVM, questo spiega nel suo blog "PresentationModel e WPF" a bit.ly/pFs6cV. Come Martin Fowler, è stato attento a non sovraccaricare i termini. Questo ci dà effettivamente una chiara comprensione di che cosa è MVVM; è una "versione di WPF specifiche del modello PresentationModel."

Figura 4 VisualWorks Model-View-Controller

Una volta che si può vedere MVC nella sua vera luce, ti aiuta a capire il vero ruolo del modello e la visualizzazione. Si tratta in sostanza di solo due posizioni per la logica di dominio/business. Dopo aver letto "Torcendo la triade", è possibile vedere le responsabilità del modello di applicazione che sono state spostate il presentatore era e che non può semplicemente sostituire il Controller con un presentatore — non avrebbe senso, perché essi non sono sinonimi.

Il modello MVP

È oltre la portata di questo articolo per andare in MVP con l'attenzione che merita; Fortunatamente, ci sono numerosi documenti che affrontare il problema, ad esempio "Torcendo la triade" e la "carta Potel", che è possibile scaricare a bit.ly/dF4gNn (PDF).

Sarà, tuttavia, si noti che l'articolo "Torcendo la triade" afferma un punto importante che ho accennato, che ha portato all'evoluzione del MVC per MVP:

"Un'altra caratteristica irritante di MVC, almeno rispetto al delfino, era che l'idea di un controller non si adattavano perfettamente nell'ambiente Windows. Microsoft Windows, come i più moderni sistemi operativi grafici, fornisce un insieme di widget nativi da quale utente interfacce possono essere costruite. Questi 'finestre' già includono la maggior parte delle funzionalità di controllore incarnato come parte del sistema operativo sottostante controllo."

Vorrei anche sottolineare dall'articolo "GUI architetture" Martin Fowler sua affermazione che "Questo bisogno di manipolare i widget direttamente è stato visto da molti come un po ' di soluzione sporca e ha contribuito a sviluppare l'approccio Model-View-Presenter." Questo è importante capire perché MVVM è radicata la mentalità del modello di presentazione in molti sviluppatori WPF; essi credono che ha "cattiva programmazione" per aggiornare la visualizzazione direttamente. Questo è vero per MVVM e il modello di presentazione, perché una volta che si fa riferimento la vista, non è possibile riutilizzare il ViewModel con una visione diversa (il motivo principale per questa regola). Questo fattore limitante è stato uno dei motivi di che Smalltalk MVC evoluti per il modello MVP. Con MVPVM, gli sviluppatori possono accedere la vista e ViewModel direttamente (esso è strettamente accoppiato), che permette la visualizzazione e la ViewModel di rimanere completamente disaccoppiati (vedere Figura 5). Visualizzazioni possono riutilizzare diversi ViewModels e ViewModels può essere riutilizzato da diversi punti di vista (come si vedrà più tardi quando discuto il modello MVPVM); Questo è uno dei molti benefici grandi di MVPVM.

Figura 5 Model-View-Presenter, supervisione Controller

Andy Bower condiviso le seguenti informazioni sul tema con me a fornire ulteriori chiarimenti:

"È forse la pena sottolineare che lo scopo di tutti questi modelli è riutilizzo tramite plugability. Mantenendo l'accoppiamento sciolto ove possibile e le interfacce più piccolo possibile dà massima riutilizzare in modo i componenti può essere ricombinato.

Si noti tuttavia che il modello ha efficacemente due interfacce che devono essere compatibili con qualsiasi associato vista e presentatore. Il primo è l'interfaccia di chiamata di funzione standard, utilizzato per il recupero e l'impostazione valori e l'esecuzione di comandi. Il secondo è l'interfaccia di evento, che deve essere uguale a quello previsto dalla vista (observer pattern). Questa combinazione di interfacce può essere definita come un «protocollo».

Ad esempio, in Dolphin MVP, un widget di lista (triade) ha bisogno di tre componenti con protocolli compatibili. Un ListModel, un controllo ListView e un ListPresenter."

Una volta che capisci perché non si vuole aggiornare una vista direttamente — e rendersi conto che questo motivo hanno contribuito a un nuovo modello di progettazione che avrebbe permesso di riutilizzare in modo efficace gli oggetti eliminando il vincolo di non essere in grado di aggiornare la vista — poi hai la possibilità di abbracciare le nuove possibilità che offre di evoluzione. Si vive in un mondo Agile e — come codice — è necessario cambiare i modelli di pensiero "per timore che la storia si ripete."

Il modello MVPVM

Mi è stato insegnato questo modello all'inizio del ciclo di vita del prisma, specificamente in 7 Drop della CompositeWPF. Perso in tutti i poteri mistici di prisma, riconosciuto il modello MVP, che mi ha aiutato a trovare qualche piano di parità. Ho imparato rapidamente (come io insegno nuovi sviluppatori) semplicemente andare per il relatore e avrete il vostro punto di partenza per capire il codice e l'applicazione. Come l'esecuzione di codice ottiene ci può essere apprese in seguito e non deve interferire con la critiche delle sequenze temporali; l'impatto delle curve di apprendimento difficile può essere gestito.

Le seguenti definizioni dei componenti MVPVM sono estratti da "Torcendo the Triad" come applicabile; Ho trovato questa informazione per essere informativo, completa e accurata, così nell'interesse di presentare a voi le migliori informazioni possibili, citerò soltanto le definizioni di questo articolo. Queste definizioni tengono vere oggi per MVPVM (vedere Figura 6) come hanno fatto per MVP nel marzo 2000 quando è stato scritto "Torcendo la triade".

Figura 6 Model-View-Presenter-ViewModel

(Nota: Prisma è il contesto di questo articolo, tuttavia, MVPVM funzionerà senza prisma; le varie componenti saranno semplicemente essere strettamente accoppiate alla loro attuazione contro risolto — loosely coupled dall'unità o Managed Extensibility Framework [MEF] contenitore di dipendenza iniezione.)

MVPVM: Il modello

"Questo è i dati su cui opererà l'interfaccia utente. In genere è un oggetto di dominio e l'intenzione è che tali oggetti non dovrebbero avere alcuna conoscenza dell'interfaccia utente". — "Torcendo la triade"

La separazione del modello da ViewModel è richiesta alle preoccupazioni di dependency injection e il suo uso all'interno di Business Logic Layer (BLL) e Data Access Layer (DAL) a Create, Read, Update, Delete ed elenco (CRUDL) persistito dati. In MVPVM, solo DAL ha accesso agli oggetti modello persistenti.

MVPVM: La vista

"Il comportamento di una visualizzazione in MVP è molto simile come in MVC. È responsabilità della visualizzazione per visualizzare il contenuto di un modello. Il modello è previsto per attivare le notifiche di modifica appropriato ogni volta che vengono modificati i suoi dati e consentono la visualizzazione di 'appendere ' il modello seguendo il modello standard di osservatore. Allo stesso modo come fa MVC, questo permette viste multiple di essere collegato a un unico modello." — "Torcendo la triade"

(Nota: Ho usato la citazione precedente per sottolineare che MVP non è un modello nuovo e che è come valido oggi come lo era quando MVP evoluti da MVC. Tuttavia, la citazione fare riferimento al "modello", mentre MVPVM utilizza il "ViewModel".)

Con MVPVM, non c'è mai la necessità di avere il codice nel codebehind. Il presentatore ha accesso alla visualizzazione e può sottoscrivere eventi, controlli di manipolare e modificare l'interfaccia utente come richiesto. Questo si dimostrò utile durante lo sviluppo dell'applicazione multi-mirati che accompagna questo articolo. ListBox utente non sarebbe rispetto l'associazione di dati per l'evento changed selezione, ho avuto modo di sviluppare un modo che avrebbe funzionato per tutte e tre le piattaforme (perché condividono lo stesso codice). Quando viene attivata la visualizzazione, io chiamo il WireUpUserListBox (vedere Figura 7, linea 174) e utilizzate la vista per ottenere un riferimento al mio controllo lstUserList (che risiede in un oggetto DataTemplate). Una volta che viene trovato, ho filo fino all'evento SelectionChanged e aggiornare la proprietà ViewModel SelectedUser. Questo funziona sul desktop, Silverlight e Windows Phone.

Figura 7 vantaggi di essere in grado di accedere direttamente alla vista

Una vista non è a conoscenza di ViewModel, così che non sono strettamente accoppiati. Come un ViewModel supporta tutte le proprietà a cui si lega una vista, può facilmente utilizzare la vista. Il presentatore è responsabile per il cablaggio viste al loro ViewModels impostando loro DataContext su ViewModel applicabile.

MVPVM: Il presentatore

"Mentre è responsabilità della visualizzazione per visualizzare i dati del modello, è il presentatore che governa come il modello può essere manipolato e modificato tramite l'interfaccia utente. Questo è dove risiede il cuore del comportamento di un'applicazione. In molti modi, un presentatore MVP è equivalente al modello applicazione MVC; la maggior parte del codice occupano come funziona un'interfaccia utente è costruito in una classe di presentatore. La differenza principale è che un presentatore è direttamente collegato alla sua vista associata affinché i due possono collaborare strettamente nei loro ruoli di fornire l'interfaccia utente per un modello particolare." — "Torcendo la triade"

Il presentatore avrà dipendenze sulle interfacce per BLLs da cui ha bisogno recuperare gli oggetti di dominio (dati), come mostrato nel riquadro sinistro di Figura 8. Utilizzerà le istanze risolte come configurato nel modulo (vedere Figura 8, riquadro di destra inferiore) o il programma di avvio automatico per accedere ai dati e popolare ViewModel.

Figura 8 sicurezza modulo codice

In genere, solo il presentatore sarà strettamente accoppiato in componenti MVPVM. Essere strettamente accoppiato alla vista, ViewModel e il BLL inter­facce. Presentatori non sono destinati a essere riutilizzati; affrontano le preoccupazioni specifiche, nonché la logica/regole di business per queste preoccupazioni. In casi dove un presentatore può essere riutilizzato attraverso applicazioni enterprise, è probabile un modulo sarebbe meglio adatto per l'attività — cioè, è possibile creare un modulo di login (progetto) che potrebbe essere riutilizzato da tutte le applicazioni aziendali. Se il codice contro un'interfaccia, il modulo può essere facilmente riutilizzato utilizzando tecnologie di iniezione di dipendenza come il MEF o unità.

MVPVM: Il ViewModel

"In MVP, il modello è puramente un oggetto di dominio e non non c'è alcuna aspettativa di (o link a) l'interfaccia utente a tutti." — "Torcendo la triade"

Ciò impedisce il ViewModel di essere strettamente accoppiato ad una vista unica, che consente di essere riutilizzato da numerose viste. Allo stesso modo, il ViewModel non avranno nessuna logica di business di applicazione, in modo ViewModels possono essere facilmente condivise tra applicazioni enterprise. Questo favorisce l'integrazione di riutilizzo e applicazione. Ad esempio, guardare Figura 8, top riquadro di destra, linea 28. Questo SecurityCommandViewModel risiede nel progetto Gwn.Library.MvpVm.xxxx (dove xxxx = Silverlight, desktop o Windows Phone). Perché un utente ViewModel sarà richiesto nella maggior parte delle applicazioni, questo è un componente riutilizzabile. Devo essere attenti a non inquinano con logica di business specifico per l'applicazione demo. Questo non è un problema con MVPVM, perché la logica di business sarà gestita dal presentatore, non all'interno di ViewModel (vedere Figura 6).

(Nota: Come le proprietà ViewModel sono popolate dal presentatore, sarò alzano NotifyPropertyChanged eventi, che emette un avviso la vista che ha nuovi dati — è responsabilità della visualizzazione di aggiornarsi ai dati dopo la notifica ViewModel.)

Il livello di logica di Business

BLLs non hanno alcuna conoscenza dei dati modello persistente. Lavorano rigorosamente con interfacce e oggetti del dominio. In genere, utilizzerai dependency injection per risolvere la tua interfaccia all'interno di BLL, così è possibile scambiare più tardi fuori DAL senza alterare qualsiasi codice a valle. Si noti che nel Figura 9, linea 34, che sto utilizzando un'implementazione di MockBll per IBusinessLogicLayer per la mia applicazione demo. Più tardi facilmente posso sostituire e con una produzione AP­mentation dell'interfaccia con una riga di codice perché ho sviluppato contro un'interfaccia.

Figura 9 registrazione BLL, DAL e comandi

Logica aziendale non si limita alla BLLs. In Figura 9, sottoscrivo tipi denominati (per IPresenterCommand) in modo che posso usare dependency injection come fabbrica. Quando l'utente fa clic su un pulsante (linee 29–33 in Figura 10), il parametro di comando viene risolto (istanziata) dalla baseclass e viene eseguito il comando applicabile. Ad esempio, il LoginCommand (Figura 8, riquadro superiore a destra) è un comando che attiverà il UserManagerView. Tutto ciò che è stato richiesto di filo questo up era un comando del pulsante in XAML e una voce la SecurityModule (vedere Figura 8, in basso a destro nel riquadro, linea 32).

Figura 10 DataTemplate per la UserCommandViewModel

Il livello di accesso ai dati

Dati persistenti dominio potrebbero archiviati in database SQL o in file di testo o XML, o recuperati da un servizio di resto. Con MVPVM, solo DAL contiene informazioni specifiche necessari per recuperare i dati. DAL restituirà solo oggetti di dominio per il livello Business Logic. Questo evita la necessità di BLL di avere conoscenza delle stringhe di connessione, file handles, servizi REST e così via. Questo aumenta la scalabilità e l'estensibilità; è possibile passare facilmente il vostro da un file XML a un servizio di nube senza alterare qualsiasi codice esistente di fuori della DAL e file di configurazione dell'applicazione. Finché la vostra nuova unità DAL test di lavoro per i processi CRUDL, è possibile configurare l'applicazione per utilizzare il nuovo DAL senza impattare applicazioni correnti e il loro uso.

Storia di comprensione, beneficiando di esperienza

Grazie ai modelli & le pratiche di squadra, sono stato in grado di raggiungere il successo per i miei clienti utilizzando tecnologie bleeding edge e modelli come MVPVM, senza errori. Ho trovato che da tenere il passo con il ritmo della squadra, tecnologie e modelli, che, come i modelli e le più recenti tecnologie, emergono, posso tirare dall'esperienza passata per aiutarmi a che più facilmente trovare la mia strada nei nuovi territori.

MVP è un modello coerenza e costante che ho visto utilizzato fin dai primi giorni dei miei studi architettonici utilizzando modelli & pratiche di progetti. Per apprezzare pienamente MVP, è necessario capire la tua storia, in particolare i componenti di MVC. Questo non è facile, a causa dei numerosi fattori discussi.

Ma comprendere il nostro passato e il motivo della nostra evoluzione, noi possiamo cogliere più rapidamente la necessità e la potenza dei modelli più recenti. Anche con prisma e tutte le sue complessità e magia, sarete in grado di aggirare una curva di apprendimento difficile semplicemente conoscendo questa storia e apprezzando la necessità per i modelli più recenti. In tutti i progetti di successo che sono stato coinvolto con dopo la comparsa di questo modello in prime gocce di prisma, MVPVM non ha rivelato problemi, dossi o muri di mattoni (attraverso l'evoluzione che sembra che sono stati eliminati), permettendo agli sviluppatori di aumentare la velocità come costruiamo applicazioni scalabili, estensibile e stabile.

Bill Kratochvil, un appaltatore indipendente, è un tecnologo di piombo e l'architetto per una squadra d'elite di sviluppatori che lavorano su un progetto riservato per un'azienda leader nel settore medico. La propria società, Global Webnet LLC, ha sede a Amarillo, Texas.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo: Andy Bower, Christina Helton e Steve Sanderson