Why Use Prism?

Question

I am interested in making a decent WPF application which will be pretty huge. Someone suggested using PRISM which we are currently looking into. We might be using the MVVM pattern to implement this application. I saw some PRISM screencasts and it seems like PRISM is mainly used to inject the regions with different views. Is that the main purpose of using PRISM?

I can always use WPF MasterPages using ContentPresenter so why should I use PRISM for the region purpose?

Answer 1

If you are already compositing your pages in a way where the various sub-components of the page are independent then PRISM (or the forerunner Composite UI Application Block) isn't really buying you much other than a recognized "standard" way of doing compositing that is documented.

The benefit of compositing is that each of the components in the user interface can be developed individually and then tied together late in the production cycle. This means that you have generated components that can be used in multiple places easily and your communication between components is happening via a well defined interface rather than the typical "throw the components on the page and talk to the state" approach.

So, if what you are doing now works, I probably would continue with it. If what you have is underdeveloped, consider something like PRISM if you have a lot of developers working on the parts and pieces and another developer or group pulling these pieces together into full blown user interfaces for the user. My experience is with the Composite UI Application Block and it brought a lot to the table in large projects, but the promised simplifications sound good for even a modest sized project.

Answer 2

If you know Composite Application Block, it's basically sort of the same. The main purpose for PRISM is to have a WPF Composite Application, in which each portion (i.e. screen portion or non visible component) of the application is loosely coupled with other part of the application.

Answer 3

Prism offers a bit more than the region system. Not exhaustively:

• the View-Model command system
• Event aggregator, for decoupled event handling (with a lot of options built-in, such as GUI thread calling, weak references etc)
• a standard way to load modules, if you need that kind of flexibility

The region system is also more than simply a "content presenter wrapper". It can be used to "push" (put a view into a region) or "pull" (let modules declare which region they populate). It also support much more than simple contentpresenter regions (ItemsControl based regions for example) and is extensible through region adapters.

Last, but maybe not least, when you adopt Prism's formalism, you bet on a common "language" (and almost framework, even if the prism team doesn't call it like that) that outsiders may already know, instead of re-inventing your own which would require someone to learn a whole new set of things. It can be a good thing for a long-lived project (provided Prism does not die too young obviously).

Answer 4

I'd emphasize the compartmentalization of developing modules here. It allows separate smaller teams to develop portions of an application and then put it together at the end.

I'd also like to say that MVVM is definitely the way to go here, but the CAG also encourages you to use dependency injection for your ViewModels, making them more testable than they would be otherwise. Of course you can use dependency injection without the CAG, but it's nice to have this formal encouragement.