How do you make sure that what you (or your designer) sees in Expression Blend is exactly what the finished product will look like? A while ago I posted about the d:DataContext attribute in Blend, and how you could leverage that to populate Blend with realistic sample data. What was awesome about that?
- You could see exactly how the finished product would look WHILE you were designing. True WYSIWYG means efficient designers!
- Blend would provide typesafe data binding (I don’t think I called this out, but bringing up the Binding dialog box shows a chooser for correct property names. Bye bye magic strings!)
- Having sample data in your ItemsPresenters/ListBoxes/TreeViews means that blend will let you edit the template in place, providing for an even more useful WYSIWYG experience.
If you haven’t tried it yet, but you are a XAML developer, I really suggest you try developing a screen in Blend when it’s populated with sample data. It’s just so easy. With unit tests on your viewmodel and sample data in Blend, you can finish a screen without ever having to press F5. Okay, maybe once, but you’ll be super happy because everything will work the way it was intended.
But at what cost?
Here are the problems that I’ve found with this approach in my own projects:
I often had to write alot of code, either dummy services to be passed into the viewmodel, or lots and lots of code to simply add things into the derived viewmodel’s collections. This code (often hacked together) got deployed, bloating my DLL file. This sucks extra for Silverlight where the DLL has to be downloaded every time) and, well, looking messy.
Depending on how your viewmodel is coded, you can’t always provide a simple design-time subclass that will populate everything you want. While Dependency Injection is awesome, we aren’t all the architects on our projects, and you might get handed a viewmodel that relies on hard coded dependencies that will do yucky things like call web services, read files or connect to a database. Other times, the ways in which the services are used are so watertight that it’s impossible (or at least it would take hundreds of lines of well thought out code) to make sure you had the right sample data for your designer.
Whenever the viewmodel or the services evolved, the design-time viewmodel needed to keep up. Often (on my project), the person adding features to the viewmodel wasn’t the person who cared about the design time viewmodel. Sometimes they took the effort to make sure the design-time viewmodel compiled, other times they deleted it. Which is fair enough, they didn’t write the code, they don’t see the point of it, all its doing is helping me design the XAML. So I’d end up restoring the file from source control, adding it back into the project, and maintaining it, which was often a lot of effort!
The solution
In the meantime, I’ve been reading around the blogosphere and found a better way to do design data in blend. It doesn’t rely on Dependency Injection (although DI is lovely), it’s easy to maintain and best of all it has NO effect on your compiled DLL. Stay tuned, having gone over (in tedious detail) the why of this new approach, I’m going write a new post about how.
