For the last couple of weeks we’ve been busy prototyping & spiking, talking to customers and partners and generally gearing up for Prism 2.0. Yesterday we held our internal Vision/Scope kick-off meeting and so I’m happy to report that the Prism 2.0 project is now officially off the launching pad!
Prism 2.0 will focus on two things:
- Extending the guidance delivered in Prism 1.0 for building composite WPF applications to also support composite Silverlight applications.
- Adding guidance for building ‘multi-headed’ applications – applications that can deliver both a desktop and an in-browser experience.
Extending Prism to support Silverlight as well as WPF essentially means that we’ll be porting Prism 1.0 to run on Silverlight (including Unity, the default Prism DI container), and implementing additional patterns and strategies to better support the RIA environment, especially around the module discovery, module loading, logging and data access areas.
Supporting multi-headed applications is primarily about implementing the patterns and infrastructure that maximize the possibility for sharing code and components between the two environments, and for allowing an application to integrate environment specific functionality so that it can take full advantage of WPF/Desktop or Silverlight/Browser specific features. The key scenario here is for applications that wants to deliver a feature rich desktop experience, as well as a wide reach browser experience. I guess the canonical example is Outlook and Outlook Web Access, but there are many other examples, especially in the line-of-business and B2C space.
Unfortunately, Silverlight and WPF are not (yet) binary compatible so code and components have to be recompiled for each target environment. The approach we are taking is to provide guidance on structuring application and module code into multiple linked projects. Each project manages all of the references, resources and code specific to the WPF or Silverlight target environment. Code that is shared is linked between two projects so that it is automatically compiled into each target. Unit tests can similarly be shared between the two environments, so that they can be written once and run against the target code in either of the two target environments. We’re looking at providing some simple tooling to help create and maintain these links.
The overall pattern then is based on defining the ‘core‘ application in shared code and then augmenting that with ‘extensions‘ that implement WPF/Desktop or Silverlight/Browser specific functionality. The core application defines the overall structure of the application and contains the application code and components that are common to the two environments. Since Silverlight is a subset of WPF, we’ve found that developing the core application on Silverlight reduces the risk of relying on an API or feature that is available in WPF but not in Silverlight.
The core application also defines the extension points into which environment specific extensions can be integrated. Extensions include, but are not limited to, modules and may be based on other extension mechanisms. Modules represent a fairly coarse grained extension and they themselves may need to be able to share code and components between the two environments. To enable this, modules can also share core functionality and be augmented with environment specific extensions using finer grained extension mechanisms, such as partial classes, etc.
Non-UI code and components are probably going to be the easiest to share, so adhering to separated UI patterns are essential in making sure that the UI and non-UI pieces of the application or modules are cleanly separated.
UI code and components will undoubtedly be more challenging. We’d like to get to the point where views, styles and themes can all be re-used across WPF and Silverlight, but as the exact level of compatibility between WPF and Silverlight becomes known in the run up to Silverlight 2.0’s release, we’ll be providing solid guidance on what works and what doesn’t and how to work around problem areas.
Clearly, the shared-code/linked-project approach is not ideal and binary compatibility would provide a much better development and debugging experience. Unfortunately, binary compatibility doesn’t look like it’s on the cards, at least for Silverlight 2.0. Hopefully the Silverlight and WPF guys can solve this problem in a future release…
We’ll be starting to drop code to our CodePlex site in the next couple of weeks and we’re planning to complete the project in January next year. We’d really like to get feedback from anyone building Silverlight applications, especially those looking to build composite applications and/or applications with a WPF and Silverlight front end so please let us know what you think and help us to deliver the best possible guidance.