In Part 1 I talked a bit about testability as one of the major drivers for why you would choose to use Prism as your guidance for a composite application. In this post I’ll try to give you some hints on how Prism address common challenges like separation of concerns, single responsibility and supporting multiple platforms.
Modularity
Modularity is what makes composite applications composite. Modularity is one of those design principles that has been around ‘forever’, and it’s just as relevant today as ever. “Modules”, “Packages”, and “Components” are all naming of the same concept; grouping related functionality together. That means that cohesion inside a module should be high; the objects within a module should work within the same context and address a common problem. If the grouping of functionality is done right then the coupling between modules should be low, because it shouldn’t be any need to reference objects that are unrelated.
The concept of modules in Prism will guide you towards the goal of high cohesion / low coupling. Modules in Prism don’t tell you how far up or down the architectural layers you should or could go, but it typically will include at least the presentation layer. Whether you choose to implement a complete, vertical slice of your application all the way down to the database, or you choose to stop right below the presentation layer is up to you. What is important to keep in mind is that a module should preferably reference neither any other modules nor the host application itself. The module must be kept as separate and isolated as possible. And because these modules are independent of its surroundings, they should be pretty easy to load into the application and by that make it possible to compose an application from these building blocks.
Maintainability
The biggest maintenance problems I’ve found myself in have usually been due to either large, difficult to follow code-behind files. Large classes and methods with a lot of functionality are in general hard to maintain, but my code-behind files from the pre-TDD-era had a distinct tendency of getting bloated. And not only were they big; they also had a lot of different responsibilities; from UI-logic and validation to business rules and data flow. And even data access in those early days (after all; that was what those on-stage demos and MSDN documentation thought us, right?).
Prism tackles the code-behind problem by showing you how to use UI design patterns to separate out functionality into presenter and presentation model classes. These classes do not have any graphical components related to them and so they lend themselves really nice to unit testing. The Patterns & Practices team chose to implement what Martin Fowler calls the Presentation Model pattern. The more WPF-specific implementation of this pattern is often referred to as a Model-View-ViewModel pattern coined by John Gossman, but because there’s no “official” documentation of the MVVM pattern (just a whole lot of blog posts), P&P chose to refer to the well-documented Presentation Model. But if you want to google your way to more intel on the UI pattern used in Prism, enter MVVM or Model-View-ViewModel as your search criteria. That way you’ll have a better shot at getting WPF or SilverLight related search results. A good start would be the MSDN article by Gossman, Dan Crevier’s early series on DM-V-VM, various blog posts on the MVVM-subject by Josh Smith, and Karl Shifflet’s M-V-VM articles.
Multi-Targeting
Should you choose WPF or SilverLight? The short and evasive answer is off course; it depends. I’m not going to elaborate on when you should choose either, but if your answer is both, then the guidance in Prism can show you how you can do this in a very smooth way. In fact; the difference between the WPF and the SilverLight version in Prism’s reference application, is 95% xaml. That is; everything but the Views are the exact same code. And by exact I literally mean the same code; instead of having the Presenter/PresentationModel-code duplicated, they actually link the SilverLight files to the corresponding WPF-files. The SilverLight projects therefore contain mostly Views, and the shared code lies in the WPF projects.
The last 5% difference implies that you can’t get all the way by changing the xaml alone; there is still some tweaking to get the WPF and SilverLight working nicely together. Since there are some subtle differences between WPF and SilverLight when it comes to functionality (SilverLight is not a pure subset, since it contains some functionality that not (yet) exists in WPF), the P&P team has used preprocessor directives on those places where they’ve had to customize specifically for the platforms.
Wrapping It Up
Building applications that are highly testable and maintainable is key for long-lived software. Splitting functionality into well-defined modules that can be developed in parallel by separate teams is key for scaling out the development process. But keep in mind that not all application will benefit from the Composite Application Guidance. Prism is not a silver bullet and it will bring more complexity into your development process. But if your needs justifies the added complexity and you know that your must ‘embrace change’ for years to come, Prism can really lay the foundation for a successful development story. And remember that Prism is guidelines, not framework.
No comments:
Post a Comment