Some time ago we announced that patterns & practices was going to be delivering a new set of guidance for building composite applications in WPF. A lot has happened since then, least of which is coming up with a new codename “Prism”. Just last week we launched the Prism site and uploaded a set of spikes which illustrate the direction.
So what is “Prism?”. “Prism” addresses the challenges around building complex enterprise WPF applications. As complexity increases and teams grow, applications become increasingly difficult to maintain. Using “Prism” enables designing a composite application that is composed of many discrete, loosely coupled modules. These modules can be developed, tested and deployed by separate teams.
In “Prism” we’re taking a new approach to addressing the problems around building composites that incorporates the community feedback we’ve hard on our past efforts. We’re investing a lot of effort into thinking not only about what we deliver, but also the adoption experience around using it.
Here are some of our over-arching goals around what we deliver:
- Built for WPF.
- Targeted specifically for WPF (though Silverlight is not out of the question in the future). This means we’re looking at how to best leverage the capabilities of WPF rather than simply porting Win-forms concepts and code.
- Not an all-imposing framework.
- Limited “Prism stuff” footprint in your applications.
- Limited number of abstractions, and small API surface area.
- Improved Adoption experience.
- Use some of it without having to take everything including the kitchen sink.
- Leverage many of your existing assets with Prism, for example use the Dependency Injection mechanism of choice. Don’t use Enterprise Library if you don’t want to.
- APIs should be intuitive and easy to work with (easy is in the eye of the beholder 😉 )
We’re setting a high bar for ourselves around the adoption experience. We’ll need your help to keep us honest 🙂