Do you use Microsoft's Prism (CompositeWPF) in commercial development?

Question

Are you using or going to use Prism? I had experience with Composite Application block (composite UI for WinForms) and can say that it's an overengineered hard to use framework. I've taken a look at Prism and it seems to be better designed e.g. simple to use and fast. What do you think?

Answer 1

I think that the learning curve for CAB was very steep but we successfully delivered a CAB app into production last year. We will definitely be looking at adopting Prism for any new desktop development we do, so I'm going to be having a look at it over the next few weeks.

Answer 2

I've glossed over the Composite Application Guidance for WPF and will definitely be incorporating (at least) the concepts into the rich client/server application we're developing.

Answer 3

I've heard great things about Prism, so you get Testability, Modularity, separation of concerns, parallel development and very low maintenance costs, at the expense of 10-20% performance hit during first time loads. Can't remember exactly how much % but it was about 10-20%.

Answer 4

I've used compositeWPF in two commercial projects so far and i can just say it's a breeze to use it. compared to the old CAB it is so "lightweight" and fresh.

They also have some nice features like compositecommand's and delegatecommand's that are really nice to use.

The only drawback so far is that you have to use DynamicResource for all shared theme's, datatemplates, ... DynamicResource resources have a little overhead in consuming cpu and memory compared to StaticResources, but I guess having everything decoupled and independent of each other makes this acceptable.

Answer 5

I am looking at this right now - and have the first architectural design meeting at 11 am. For the type of system that I look after see my answer to this SOpost on system integration

Answer 6

We have also just started to look at Prism at my company. It would be great to hear more on what kind of applications you are using it for? For instance we need to know if it is possible to use Prism (and WPF for that matter) for smaller apps that aren't at the "Enterprise" level?

Answer 7

I am not exactly a user of it, but it was er my idea. :-) All I can say is that we had explicitly set out to learn from the past. We heard tons of feedback on the complexity of CAB (http://blogs.msdn.com/gblock/archive/2007/05/27/is-cab-complex-and-if-so-why.aspx) , how it bound you to a very static path, how it was extremly heavyweight etc. For some customers it was a godsend, others hated it. With Prism we set out for a much more lightweight (http://blogs.msdn.com/gblock/archive/2008/05/08/prism-vs-framework-xxx.aspx), and more broadly adopotable solution.

Only you can tell us if we got there, but we absolutely were intentional on meeting that goal. If we didn't, I give you full permission to flame me!

Answer 8

Having used CAB/SCSF/MCSF in the past, I have found Composite WPF a joyfully easy and powerful architectural foundation for a modern smart client line-of-business enterprise application on WPF. Unlike CAB, you can take as much or as little as you like from it, choose your own IOC container and logging implementatons, and extend/customise as necessary. It does not have the very steep learning curve that CAB did, though developers are assumed to have knowledge of modern UI patterns and technologies such as IOC Containers, etc. Highly recommended. Long live the Smart Client! :)

Answer 9

Id definitely recommend composite WPF. Its far more lightweight than CAB/SCSF. CAB had a very steep learning curve and just getting the required components on your dev machine was a pain.

Composite WPF has done away with many of the more confusing elements that came with CAB (workItems comes to mind). It also follows a more conventional approach to dependency injection and Ioc - If you have any experience with windsor castle or other containers the new Unity container will be easy to pick up.

The documentation is far better and goes to great length to explain the principles the framework uses before explaining how they're implemented under composite WPF. The sample implementation is good also.

Answer 10

Short answer: Yes, It comes highly recommended from myself.

Why?

The WPF CAG helps create a modular, decoupled, maintainable, expandable WPF application.

Documentation rocks, and with some up front learning: dependency injection, concept of modules, composite events (using the event aggregater) you are pretty much there.

Long answer:

I have designed and developed 6 full applications using 'PRISM', 2 of which were enterprise standard.

Developing applications with 'PRISM' (CAG WPF) I find to result in a well structured and loosely coupled in nature, and with ease I can plug in 'Version 2' of any aspect of my system (be it a data provider, service, View element etc), with no adverse affect on other elements of the system.

How and why?

PRISM contains nice mechanisms such as the RegionManager (for loading views in and out), EventAggreator (for registering, publishing and subscribing to events, I think of this a dependency Injection container for events) and the Container (Dependency Injection).

Seperation and decoupling from dependencies

PRISM is built with the concept of Dependency injection allowing for Views, Services etc to be accessed from an area which only holds a reference to an interface, so modules are ignorant of how implementations of it dependencies.

PRISM builds on the concept of loading 'Modules' in at runtime, when a module is loaded it dependencies are loaded into it automatically. (It also gives you a nice clean mechanism to state which modules depend on others i.e. a 'WeatherBrowserModule' may depend on a 'WeatherDataProviderModule'.

Components with no knowledge of each other working together flawlessly

The actual View of your app can be constructed from many different UI Modules, that can be swapped in at runtime. Loading different controls into the view (e.g. you may wish to load a version 2 of a UI component which displays data in a new 3D chart).

Communication = Publish and Subscribe

Communication between modules can take of the form of using the PRISM Composite Events (CompostiteWpfEvent) which allow for strongly typed Events to be published and subscribed to.. The composite event system allows for events to be published (from anywhere) and subscribed to anywhere (nice Pub Sub pattern). These events are strongly typed so allow meaningful data to be communicated with ease, and all areas of the application which care about the event can access the event notification and the attached data with true ease (whilst not knowing or caring where the event was fired).

Events are registered and resolved using the EventAggregator which is available to all Modules in the system.

This results in the 'Modules' maintaining separation, being easily updated / replaced completely.

Speed?

I have found no performance faults, if anything loading components in modularly has increased performance as I load and use as needed.

Speed of dev?

Due to the nice communication and decoupled modular model I find it easy to integrate and develop new functionality.

Overhead?

There is the initial overhead of learning how to compose your system, how build the UI using modules and loading 'Views' into Regions, and building & loading Modules..

Check these screen casts out and make up your own mind.

Brian Noyes on Prism: http://www.dnrtv.com/default.aspx?showNum=124 Brian Noyes on Prism Events and Commands: http://www.dnrtv.com/default.aspx?showNum=132

Hope this give you and overview and helps you make an informed decision.

Regards..