Part 1: Divide and Conquer
In this series of posts, I’m planning to address the use of Expression Blend and Sample Data when used in an MVVM-based Silverlight project. The aim is to provide a useful mechanism for both developers and designers to be able to work on a project together, without one having to depend too much on the other.
First, a little background information.
I’ve been working on Silverlight projects pretty much solidly for the last couple of years now (since Silverlight 2 beta time) and have been using the MVVM approach for the last few projects (since we moved to SL3).
The team I work in has the benefit of having a couple of full-time designers in it (although I can create a UI, I’m a long way from being a designer). The designers spend nearly all of their time using Blend, whereas myself and the other developers spend most of our time in Visual Studio.
Since adopting MVVM for our projects, it has made it easier to separate the UI from the code, but there have still been a few difficulties:
- At the start of the project, the designers can see everything in the solution, but the further along the project gets, the more problems they have had with getting everything to render. This is mostly due to the increased dependency on bindings as the views develop.
- The designers use very different machines to the developers – developers have SQL Server installed, run IIS and have it all configured so that the Silverlight apps can access the appropriate services; designers have none of those tools and shouldn’t need to be concerned about things like the service or configuring IIS on their machine
- We had to produce a rather convoluted solution to get around the above point
What do I mean by ‘convoluted’? How about this:
- A designer-specific solution that includes the .Web project and any projects that contain Silverlight controls
- A developer-specific solution that uses Post-Build Events to copy the .dll files generated by any Silverlight class libraries into a common folder for the Silverlight control projects to use
- Multiple test pages, with some code-behind to specify whether you’re using the app as a developer or designer
- A whole project dedicated to providing data for the designers so that when they run the application by pressing F5 in Blend they can see something
Now, there are approaches to solving these problems (using the design DataContext for example) but none of the solutions we saw fixed 100% of the issues.
For quite a while now the designers and myself have been discussing the matter and trying to work out how to fix all of this. Fortunately for us, a few people have blogged about ways that help achieve our goal. The main work came about because of John Papa’s ViewModelLocator pattern and Jeremy Likness’ blog about IApplicationService.
I had already been looking into MEF (used in John Papa’s VMLocator and the subject of many posts on Jeremy Likness’ blog) and so I set about working out how to achieve the following:
- Use Blend’s Sample Data facility when in Design mode (either VS or Blend)
- When you run the application (press F5) from Blend, you use the Sample Data created in Blend
- When you run the application from Visual Studio, you can either use the Blend Sample Data or run using the WCF service to populate values
- Remove the dependency on having a DesignTestPage and DevTestPage
- Allow the designers to modify the Sample Data themselves
I still like having the separation of projects for the designers and developers, and I know that the designers like it too.
That’s enough background for now. My next post will be on detecting whether you’re running from within Blend or Visual Studio (or indeed deployed on an IIS server)