We recently started a project for an LOB that acts as a very specific ERP. The requirements were simple, build a system in .NET, that contains all functionality of an old system and make it robust and extensible. Well, looking at the list of roughly 200 use cases we needed to cover, and taking into account it needed to be a WinForms application, I immediately started to be afraid of building a monolithic, Visual Studio Designer generated app.
I wanted to use concepts like modularization, avoiding coupling as much as possible, making clear dependencies and also teaching new and better development practices. I wanted to use some kind of composition framework.
The old Composite Application Block seemed a bit rusty, the concepts a bit tricky to understand, and even harder to explain to a team of developers. So, I started looking into fresher libraries, with better conceptualization. I found and finally decided to use the newer Composite Application Guidance for WPF and Silverlight.
But hey, how can you use this with WinForms?
Well, it’s possible. Composite WPF library is extensible and even though it gives an implementation, nobody stops you in replacing components with your own or using only parts of it. Thanks to Brian Noyes and his nice post on Composite Extensions for Windows Forms the starting point was clear and made things seem possible.
Helped by a few enthusiats at work, we rolled out our sleves and put down a set of classes that implement the concepts of CompositeWpf, but this time using the Windows Forms “windows”.
We had to implement from scratch or adapt concepts like ClickCommandBehavior, Region, RegionManager.
Still, the toughest process was to support the Model-View-Presenter pattern. So, we decided that all our Views will implement an IView interface, that any IView can be hosted in a Region. But hey, how do you activate a View (which in our case are User Controls) in a Region? Well, our solution was to build a set of Host controls. For example, activating a View in a Dialog Region (Modal), is as easy as creating a Form and adding the View inside it. Of course, plumbing and hooking some events is needed, but for the developer, the feeling is the same as for the Composite WPF code, you just Activate a View in a Region.
Another tough part was to support UI Composition in Windows Forms. Imagine you have a Person, a Company and they each have an Address. Now, you want to include the Address View (edit or read only mode) in both screens for editing a Person and a Company. Well, this seems good practice: we promote re-usability, we have less code to hunt for bugs, we get consistency and so on. But how to do it in WinForms? Well, since our Views are User Controls, we can nest them, but how? Well, it was fairly straight forward. We built yet another user control that acts as a Host for any IView. Plumbing some events, exposing some interfaces and we were done.
Oh, I almost forgot… a good introduction to Composite WPF technical concepts is available on the dedicated MSDN page.
The result, so far, is that we are able to develop fast, with clean code, employing good concepts and laying the ground for better testing of our software deliverables.
