Il presente articolo è stato tradotto automaticamente.

Oltre MVP

Estende il modello MVP per classi di Enterprise immettere Application Architecture UI

Haozhe Ma

Modello View Presenter (MVP) rappresenta un rivoluzionarie per gli in pensando modelli UI e lo rende evidente che le finestre di progettazione dell'interfaccia utente deve mantenere la separazione di interesse nelle proprie applicazioni.

Tuttavia, esistono molte diverse interpretazioni di modello MVP. Ad esempio, alcune persone hanno per concessa che il modello MVP rappresenta in modo esplicito il modello di architettura di interfaccia utente. Questo vale non esattamente per applicazioni aziendali. Applicazioni di livello aziendale rispetto ad altri tipi di applicazioni di interfaccia utente, necessario gestire molti requisiti diversi, più le parti coinvolte, maggiore complessità e le dipendenze tra molti altri sistemi, ad esempio servizi di altre applicazioni e così via. Queste caratteristiche particolari hanno richiesto l'architettura di interfaccia utente di applicazioni aziendali che più enfasi sulla flessibilità, gestibilità, riutilizzo, la coerenza di implementazione e decoupling funzionalità aziendali dalla tecnologia sottostante per evitare le dipendenze su specifici prodotti e fornitori.

Se solo il modello MVP stesso viene applicato come il modello di architettura di interfaccia utente per applicazioni aziendali, verranno generati alcune domande. Di seguito ne sono elencati alcuni:

Un'applicazione aziendale tipica contiene numerose visualizzazioni e gli eventi che si verificano in una visualizzazione possono influire sulle altre visualizzazioni. Ad esempio, facendo clic su un pulsante in una schermata potrebbe causare una finestra popup visualizzare e i dati di un altro dello schermo possono essere aggiornati allo stesso tempo. Chi è responsabile del controllo logica del flusso di schermo di questo tipo? Controllate questo da ogni visualizzazione dell'accoppiamento relatore?

In un'architettura orientata ai servizi (SOA), l'interfaccia utente dell'applicazione ottiene in genere informazioni tramite i servizi. L'interfaccia utente, ad esempio, sarebbe necessario chiamare un proxy client generati del servizio WCF per chiamare il servizio WCF per ottenere i dati. È una buona progettazione per il relatore chiamare direttamente questo proxy client del servizio? Se questi servizi vengono implementati con diverse tecnologie o se vengono modificati i modelli di servizio, come progettare l'architettura di interfaccia utente in modo che è possibile ridurre al minimo l'impatto di tali modifiche sull'implementazione dell'interfaccia utente?

Seguendo questo flusso di concetti, alcune implementazioni potrebbero utilizzare modelli di proxy client generati servizio all'interno dell'applicazione. Esistono eventuali rischi di questa operazione? Se è necessario un modello di UI dedicato, quale parte sarà responsabile di fornire il mapping tra il modello di proxy client del servizio e il modello di interfaccia utente?

Non si tratta di nuove domande e molti altri modelli sono stati introdotti per colmare il divario. Ad esempio, Modello di applicazione controller è stata introdotta per assumersi la responsabilità di controllo del flusso spostamento.

Ho pensato che sarebbe utile raccogliere alcune di queste diverse discussioni estensione MVP e disegnare una visione olistica dell'architettura di interfaccia utente. Osservando il problema dal punto di vista dell'applicazione a livello aziendale, questo consentirà ai progettisti UI riconoscere le parti chiave sono necessari per la progettazione dell'interfaccia utente e definiscono un modello coerenza all'implementazione di Guida dell'interfaccia utente dell'applicazione.

Verrà utilizzato il termine “ modello MVP ” in tutto l'articolo ma effettivamente il modello MVP originale è stato ritirato e due varianti di MVP originale sono attualmente disponibili. Uno è il criterio Visualizza passivo e l'altro è il modello di supervisione controller. Sebbene uno soddisfa determinati scenari e hanno vantaggi e svantaggi dell'architettura di interfaccia utente descritto in Nella figura 1 è principalmente in base ed estesa dal criterio vista passiva. Ciò certamente non significa Impossibile essere costituita architettura di interfaccia utente in base al modello di supervisione controller, ma si tratta di preferenza personale.

Figura 1 Architettura di interfaccia utente in base al modello Visualizza passiva

Let’s iniziare la discussione con una conoscenza approfondita di ciò che costituisce l'architettura di interfaccia utente estendendo il modello MVP. Nella figura 1 Mostra le parti chiave sono necessari da una visualizzazione ad alto livello dell'architettura di interfaccia utente. In questo diagramma sono state introdotte sette parti principali: Visualizzazione, Presenter, modello UI, controller del flusso di processo, servizio agente, modello proxy client del servizio e proxy client del servizio.

Guarda

Visualizzazione segue fondamentalmente il ruolo di viste nel modello di visualizzazione passiva. Visualizzazione presuppone un semplice elenco di responsabilità, inizia con la gestione di layout di visualizzazione dell'interfaccia utente e la logica di presentazione specifico.

È responsabilità di secondo della visualizzazione per la generazione di eventi per il relatore e richiede diverse implementazioni per gestire questa responsabilità. Visualizzazione in primo luogo, deve implementare l'interfaccia IView. Per assicurarsi che vi sono alcuni se qualsiasi implementazione ha conseguenze negative sulla logica relatore e per fornire funzionalità di testing, Presenter deve interagire con visualizzazione tramite un'interfaccia IView.

In secondo luogo, visualizzazione deve definire proprietà pubbliche in grado di interagire con relatore. Nel modello di visualizzazione passiva View non passa i dati Presenter. Si tratta invece fino a per scegliere i dati a che è interessato dalla visualizzazione relatore. Questo tipo di implementazione ulteriormente riduce l'associazione del contratto tra View e Presenter e separa più chiaramente le responsabilità.

Una domanda, è però su quale tipo di dati deve utilizzare la proprietà delle visualizzazione. Il metodo ideale è disporre Visualizza definire queste proprietà utilizzando semplici solo tipi, ad esempio stringa, integer e così via. Tuttavia, in un'implementazione reale, può essere noioso se definisce la visualizzazione dati in questo modo. È possibile esporre una proprietà dati facendo riferimento a tipi complessi, quali le definizioni di modello dell'interfaccia utente. Consente di bilanciare purezza con considerazioni sull'implementazione dell'architettura.

Terzo, visualizzazione deve inoltre chiamare Presenter operazioni quando si verificano eventi nella visualizzazione. La visualizzazione è possibile chiamare Presenter direttamente senza passare tutti i dati. Non è disponibile nessun accoppiamento progettazione tra View e Presenter poiché View e Presenter sono sempre accoppiate. È una buona progettazione disporre di una sola operazione Presenter dedicata a un evento di visualizzazione.

Responsabilità l'ultimo della visualizzazione è per rispondere agli aggiornamenti del valore di proprietà. Presenter aggiorna la proprietà delle visualizzazione per indicare una modifica. Visualizzazione dispone di conoscenze per stabilire come rispondere a tali modifiche. Potrebbe andare avanti per aggiornare la visualizzazione in modo che rifletta la modifica dei dati o potrebbe decidere di non intraprendere alcuna azione.

Relatore

Relatore segue essenzialmente il ruolo di moderatore nel modello di visualizzazione passiva. Tuttavia, in questo caso, il relatore non determina flusso del processo. Il relatore accetta le richieste di evento dalla visualizzazione e pubblica le richieste di evento controller controller scelta al passaggio successivo. Poiché relatore non gestirà la logica del flusso di processo, non è possibile sapere se le richieste di evento da visualizzazione avrà alcun impatto sulle altre visualizzazioni. In modo che quando il relatore riceve le richieste di evento da visualizzazione, verrà immediatamente pubblicare eventi corrispondenti in modo che tale controller possa rispondere alle richieste di questi eventi e decidere il successivo passaggio di processo. Relatore presuppone che non può proseguire ed eseguire alcune operazioni fino a quando non viene richiesto dal controller.

Controller decide se è necessario eseguire le operazioni del relatore. Quando un'operazione Presenter viene chiamata dal controller, Presenter esegue quindi le azioni, ad esempio per recuperare dati tramite un agente di servizio. Se è necessario intraprendere azioni contro servizi relatore, che non tramite il servizio agente. Passare i parametri necessari per l'agente di servizio e riportare i risultati dall'agente di servizio.

Quando è pronto per inviare una notifica sulle modifiche dei dati Visualizza relatore, eseguirà tale operazione aggiornando i valori delle proprietà della visualizzazione. Quindi è fino alla visualizzazione per decidere come visualizzarli. Come accennato in precedenza, Presenter interagisce con visualizzazione tramite l'interfaccia IView anziché accedere direttamente l'oggetto View. Poiché l'istanza di visualizzazione è stato passato a Presenter già all'avvio Presenter, Presenter dispone già di un'istanza di visualizzazione per la gestione.

Infine, Presenter possono accedere al modello di interfaccia utente e può inserire in una cache se sono necessario accedere in seguito i dati del modello dell'interfaccia utente.

Processo di flusso controller

Il controller di flusso del processo è simile al modello Application Controller. La differenza è che è l'unica responsabilità del controller flusso processo descritto di seguito per controllare il flusso di processo basato su eventi tipizzati generati dal relatore. Flusso del processo non è limitato al flusso di spostamento dello schermo. Include inoltre controllare l'ordine di relatore azioni correlate alle richieste di evento.

Processo di flusso controller sottoscrive eventi pubblicati dal relatore e risponde solo per gli eventi pubblicati dal relatore. Questi eventi sono eventi tipizzati. In altre parole, Process Flow Controller non risponde a un evento generico.

Poiché il processo del flusso controller risponde solo a un evento tipizzato, un flusso di processo effettivamente è già stato predeterminato quando si verifica un evento. Ciò semplifica la logica del processo di flusso del controller. Ogni evento pubblicato dal relatore contiene i dati necessari per Process Flow Controller eseguire quando avviare altre operazioni Presenter.

Processo di flusso controller avvieranno Presenter e istanze di visualizzazione correlate se non sono state avviate ancora. Inversione del controllo (IoC) sarà necessarie a causa di problemi di riferimento incrociato. Fornisce inoltre un'architettura loosely coupled tra Presenter e controller di flusso del processo.

Modello dell'interfaccia utente

Modello di UI segue fondamentalmente il ruolo di modello nel modello di visualizzazione passiva. Nella vista passiva, modello veramente non esegue quantità di lavoro e fornisce semplicemente la definizione del modello di struttura. Inoltre, come descritto nella sezione Presenter, Presenter è responsabile della gestione dello stato di modello.

È possibile chiamare questo modello di UI anziché semplicemente modello ha lo scopo di differenziare dal modello di proxy client di servizio che verrà descritto più avanti l'articolo.

Modello dell'interfaccia utente definisce la struttura del modello adatto per l'interfaccia utente dell'applicazione logica di gestione. La definizione del modello di UI può essere esattamente lo stesso aspetto come modello di servizio client proxy. Tuttavia, in alcune situazioni, soprattutto se l'interfaccia utente deve visualizzare dati provenienti da più origini di servizio, è necessario un modello di UI restructured che saranno diversi da del modello di proxy client del servizio.

Agent Service

Servizio agente svolge un ruolo intermedio tra Presenter e proxy client del servizio. Il servizio nel nome non è necessariamente un servizio Web. Rappresenta tutte le risorse che forniscono dati o eseguire la logica business. Ciò potrebbe essere un servizio Web, ma può anche essere semplicemente I/O di file.

Proxy client del servizio ha significato specifico della tecnologia del servizio Web. In questo caso, utilizzare proxy del servizio client per rappresentare il gateway per un servizio.

L'implementazione di proxy client del servizio è tecnicamente specifico. Dal punto di vista del relatore, sarebbe piuttosto non sapere come i dati vengono trasmessi o forniti. Tali dettagli tecnicamente specifici potrebbero essere nascosti all'interno del servizio agente. Pertanto, il livello del servizio agente protegge Presenter da vengano interessati da modifiche tecnologia di implementazione del servizio, servizio di gestione delle versioni, le modifiche al modello di servizio e così via.

Servizio agente fornisce operazioni per Presenter interagire con. Se un tipo complesso deve essere passato a queste operazioni, è necessario definire un tipo complesso in modello dell'interfaccia utente. Questo vale anche per il tipo restituito di operazione. È quindi possibile passare le chiamate di operazione a operazioni proxy client del servizio corrispondente. In alcuni casi, un'operazione del servizio agente può avviare più chiamate operazione proxy client del servizio.

Poiché le operazioni del servizio agente di tipi complessi definiti nel modello dell'interfaccia utente, le operazioni del servizio agente è necessario eseguire il mapping dal modello di UI al modello di servizio client proxy quando si chiamano le operazioni proxy client del servizio. Quando le operazioni del servizio agente devono restituire risultati Presenter, sono sarebbe associati dal modello di servizio client proxy al modello di UI dopo avere ottenuto i risultati dalle operazioni di proxy client del servizio.

Potrebbe trattarsi di un processo noioso. Tuttavia, sono gli strumenti disponibili per il mapping da un modello struttura a un'altra struttura di modello semplice, in modo che questo diventano più di un processo di progettazione di una sola volta.

Modello di servizio client proxy e proxy client del servizio

Proxy client del servizio della tecnologia del servizio Web fornisce l'accesso locale per il client del servizio anche se il servizio è ospitato in remoto. In questo articolo sarebbe descriverò proxy client del servizio gateway per il servizio. Modello di servizio client proxy rappresenta la definizione del modello di contratto di servizio.

Proxy client del servizio passa le chiamate a servizi e restituisce le risposte del servizio. Se il servizio è implementato con servizi Web ASP.NET (ASMX) o le tecnologie di Windows Communication Foundation (WCF), del proxy client del servizio può essere generato automaticamente.

Modello di servizio client proxy rifletteranno la definizione della struttura modello contratto assistenza.

Esempio di implementazione

Per illustrare l'architettura di interfaccia utente descritto in Nella figura 1 let’s esaminare un'applicazione Windows Form riportato di seguito viene illustrata l'implementazione. Questa applicazione di esempio è incluso nel download di questo articolo.

Questa applicazione di esempio è necessario innanzitutto caricare un elenco di regioni. Quando è selezionata un'area, vengono visualizzati i clienti appartenenti alla regione. Quando si seleziona un cliente, una finestra di query di intervallo di tempo verrà visualizzata. Dopo un'ora di inizio e fine vengono immessi, verrà visualizzato un elenco di ordini che appartengono al cliente selezionato nella griglia di dati nella schermata principale.

Utilizzerò lo scenario di visualizzazione di un elenco di regioni per spiegare come l'architettura di interfaccia utente in Nella figura 1 viene implementato nell'applicazione di esempio. Nella figura 2 viene illustrata la sequenza di chiamata per questo scenario.

Nella figura 2 Sequenza di chiamata dell'interfaccia utente

Quando viene caricato il form principale su schermo, viene innanzitutto avvia l'interfaccia Presenter e passa l'istanza corrente di visualizzazione costruttore del relatore:

private void MainView_Load(

  object sender, EventArgs e) {



  _presenter = new MainPresenter(this);

  ...

}

L'avvio istanza MainPresenter causerà costruttore del MainPresenter per assegnare prima passati in MainView istanza di una variabile privata di tipo IMainView. Quindi si avvia un'istanza di controller e passa l'istanza corrente di relatore al costruttore controller:

public MainPresenter(IMainView view) {

  _view = view;

  _controller = new Controller(this);

}

Avvio istanza controller causerà il costruttore assegnare l'istanza MainPresenter passato a una variabile privata di tipo IMainPresenter. Questo costruttore definisce inoltre il gestore eventi per prepararsi a rispondere a eventi pubblicati del MainPresenter quali RetrieveRegions:

public Controller(IMainPresenter presenter) {

  _mainPresenter = presenter;

  ...

  _mainPresenter.RetrieveRegions += (OnRetrieveRegions);

}

Nuovamente nell'evento caricamento form schermata principale, Presenter viene chiamato per recuperare le regioni dopo che l'oggetto Presenter viene avviata:

Private void MainView_Load(object sender, EventArgs e) {

  ...

  _presenter.OnRetrieveRegionCandidates();

}

Quando il relatore riceve questa chiamata, pubblica innanzitutto l'evento RetrieveRegions invece di anticipo si prevede di recuperare le aree. L'evento RetrieveRegions nell'interfaccia IMainPresenter è stato definito e implementato in MainPresenter:

public event EventHandler<RetrieveRegionsEventArgs> 

  RetrieveRegions;

  ...



public void OnRetrieveRegionCandidates() {

  if (RetrieveRegions != null) {

    RetrieveRegions(this, 

      new RetrieveRegionsEventArgs());

  }

}

Nella classe controller, poiché è stato registrato un gestore eventi per RetrieveEvents, può rispondere all'evento RetrieveRegions:

private void OnRetrieveRegions(

  object sender, RetrieveRegionsEventArgs e) {



  _mainPresenter.HandleRetrieveRegionsEvent();

}

Controller decide che il flusso del processo deve restituire il controllo MainPresenter e richiede di continuare a recuperare le aree. Se è necessario avviare i relatori diverso MainPresenter Controller, è possibile utilizzare Unity Framework di eseguire tale operazione.

Operazione HandleRetrieveRegionsEvent del MainPresenter, chiama Agent Service per recuperare le aree. Per semplicità, mio esempio effettivamente non implementa il servizio. Scrive solo alcuni dati fittizi per rendere la funzione dell'applicazione. Una volta restituito un risultato dall'agente di servizio, si noti che MainPresenter non passare dati MainView. Viene invece aggiornato RegionCandidates proprietà del MainView:

public void HandleRetrieveRegionsEvent() {

  RegionAdminServiceAgent agent = 

    new RegionAdminServiceAgent();

  List<Region> regionCandidates = agent.RetriveRegions();

  _view.RegionCandidates = regionCandidates;

}

Proprietà RegionCandidates del MainView, gestisce la visualizzazione delle regioni:

public List<UIModel.Region> RegionCandidates {

  set {

    _regionCandidates = value;

    PopulateRegionCandidates();

  }

}

Si tratta dell'intera sequenza di recupero delle aree e visualizzandoli nel MainView. In modo definito implica più operazioni rispetto a chiamare semplicemente il servizio agente per ottenere aree. Tuttavia, quando pensando dal punto di vista di un'applicazione a livello aziendale, non solo viene introdotto un'accoppiamento progettazione, promuove inoltre un modello di implementazione coerente. Manutenzione e trasferimento di informazioni per un team di sviluppo possono semplificare notevolmente.

Solo un commento ulteriori informazioni su questo esempio di codice: l'intera sequenza inizia con il primo evento di caricamento di Windows Form. Un'implementazione più avanzata potrebbe iniziare con il controller e consentire controller decidere qual è il primo form da caricare.

Conclusioni

In questo articolo ho presentato un approccio alla progettazione dell'architettura di interfaccia utente basata sull'estensione di modello MVP. Le applicazioni di interfaccia utente possono risultare complicate e sono disponibili molti tipi diversi di progettazione dell'interfaccia utente dell'applicazione. La tecnica presentate in questo articolo rappresenta una delle molte di queste soluzioni. Questa è una tecnica utile in molte situazioni, ma assicurarsi che risponde alle proprie esigenze prima di implementarlo.

Sul mercato sono già molti framework UI e molte si basano su MVP, Model View Controller o sviluppati come estensioni di queste due motivi. Un buon primo passaggio consiste nel verificare le parti principali sono implementate da tali Framework, come ad esempio, il modo è possibile ricavare l'architettura di interfaccia utente in questo articolo. Non è una buona architettura pensare che rientrano nei dettagli di implementazione senza prima considerare la visione. Avvio con una vasta conoscenza dell'architettura del problema a portata di mano assicura non solo che i problemi fondamentali dell'architettura di sistema sono stati risolti, ma anche che può essere seguito uno schema ripetibile e ben thought out.

Infine, nell'esempio di questo articolo, l'implementazione di controller è stato creato con C#. Un approccio più efficace, è possibile utilizzare una tecnologia di flusso di processo, ad esempio Windows Workflow Foundation, che possono consentire a una progettazione più flessibile e l'implementazione. Tuttavia, questo dettaglio di implementazione tecnica non influenzerà il principio alla base dell'architettura di interfaccia utente descritti in questo articolo.

Per ulteriori informazioni su modello MVP, vedere Numero di agosto 2006 di MSDN Magazine (informazioni in lingua inglese).

Zhe Ma è un architetto tecnico dell'architettura Enterprise Unum Group, vive a Roma, Maine. È possibile contattarlo all'indirizzo zma@unum.com.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Don Smith