Perché usare Prism?

Question

Sono interessato a fare una buona applicazione WPF che sarà abbastanza grande. Qualcuno ha suggerito di utilizzare PRISM che stiamo attualmente esaminando. Potremmo utilizzare il pattern MVVM per implementare questa applicazione. Ho visto alcuni screencast PRISM e sembra che PRISM sia utilizzato principalmente per iniettare le regioni con viste diverse. È questo lo scopo principale dell'uso di PRISM?

Posso sempre utilizzare WPF MasterPages utilizzando ContentPresenter, quindi perché dovrei utilizzare PRISM per lo scopo della regione?

Answer 1

Il prisma offre un po 'più del sistema regionale. Non esaustivo:

• il sistema di comando Visualizza-Modello
• aggregatore eventi, per la gestione degli eventi disaccoppiato (con un sacco di opzioni integrate, come la vocazione filo GUI, riferimenti deboli ecc)
• uno standard modo per caricare i moduli, se avete bisogno di quel tipo di flessibilità

Il sistema di regione è anche più di un semplice "content presenter wrapper". Può essere usato per "spingere" (mettere una vista in una regione) o "tirare" (lasciare che i moduli dichiarino quale regione popolano). Supporta inoltre molto più delle semplici regioni contentpresenter (ad esempio, le regioni basate su ItemsControl) ed è estendibile tramite adattatori di regioni.

Ultimo, ma forse non meno importante, quando si adotta il formalismo di Prism, si scommette su un "linguaggio" comune (e quasi quadro, anche se il team di prismi non lo chiama così) che gli estranei potrebbero già sapere, invece di re-inventare il tuo che richiederebbe a qualcuno di imparare una nuova serie di cose. Può essere una buona cosa per un progetto di lunga durata (a condizione che il Prisma non muoia troppo giovane ovviamente).

Answer 2

Se stai già componendo le tue pagine in un modo in cui le varie sottocomponenti della pagina sono indipendenti, PRISM (o il precursore Composite UI Application Block) non ti sta davvero comprando molto oltre a uno "standard" riconosciuto modo di fare compositing che è documentato.

Il vantaggio del compositing è che ciascuno dei componenti nell'interfaccia utente può essere sviluppato individualmente e quindi legato insieme in ritardo nel ciclo di produzione. Ciò significa che hai generato componenti che possono essere utilizzati in più posti e che la comunicazione tra i componenti avviene tramite un'interfaccia ben definita piuttosto che il tipico approccio "lancia i componenti sulla pagina e parla allo stato".

Quindi, se quello che stai facendo ora funziona, probabilmente lo farei. Se quello che hai è sottosviluppato, considera qualcosa come PRISM se hai un sacco di sviluppatori che lavorano su parti e pezzi e un altro sviluppatore o un gruppo che trascina questi pezzi in interfacce utente complete per l'utente. La mia esperienza è con l'UI Application Block composito e ha portato molto in tavola in grandi progetti, ma le semplificazioni promesse sembrano buone anche per un progetto di dimensioni modeste.

Answer 3

Se si conosce Blocco applicazioni composite, è praticamente lo stesso. Lo scopo principale di PRISM è di avere un'applicazione composita WPF, in cui ogni porzione (cioè porzione di schermo o componente non visibile) dell'applicazione è liberamente accoppiata con altre parti dell'applicazione.

Answer 4

Vorrei sottolineare la compartimentalizzazione dei moduli di sviluppo qui. Permette a gruppi separati più piccoli di sviluppare porzioni di un'applicazione e quindi metterlo insieme alla fine.

Vorrei anche dire che MVVM è sicuramente il modo di andare qui, ma il CAG ti incoraggia anche a usare l'iniezione di dipendenza per i tuoi ViewModels, rendendoli più testabili di quanto non sarebbero altrimenti. Naturalmente è possibile utilizzare l'integrazione delle dipendenze senza il CAG, ma è bello avere questo incoraggiamento formale.