I’ve been experimenting with the use of Expression Blend as a tool in the life-cycle for day-to-day development for a typical .NET developer that might be writing an application using Silverlight with some sort of implementation of MVVM.
Having used Visual Studio 2010 as my primary, all-in-one tool for developing applications, I was somewhat sceptical of using Blend. When I had tried the earlier versions of Blend, I didn’t like the look of some XAML it generated. Moreover, I simply couldn’t see the point of it – why run two applications to do something when one can do it. I’m no UX designer – I’m a .NET developer! So why should I use some code-gen tool to write badly-formed XAML when I can hand-craft it and do a much better job of it?
However, I recently became more and more frustrated with the performance and reliability (or lackof) within VS2010 when it comes to authoring XAML-based UIs, and so a couple of weeks ago I decided to try Blend again, and I think that this time I’ve “got it”. I’ve been using Blend along with Visual Studio 2010 to develop a relatively small Silverlight application, and have found it to be a powerful and useful tool in the arsenal of an application developer.
Whilst the VS2010 XAML editor isn’t that bad, there are a number of benefits that I’ve found in using Blend to VS2010: -
Because the Blend designer is much more powerful than VS2010, I can see how styles and data templates will look without having to run the application. You’d be amazed how much time this saves.
The Blend editor is much, MUCH quicker and more responsive than VS2010. It got so bad with me in VS2010 that I ended up writing all my views in XAML-only mode at one stage. With Blend, 90% of what I do is in the UI mode; occasionally I’ll switch to XAML or split view to fine tune something, but the tool is generally fine for every day UI design.
Animations and Visual States are much easier to design in Blend.
The XAML editor is much quicker in Blend, because it doesn’t have as powerful XAML intellisense as VS2010. This is actually not usually much of a problem because, as I said, you end up using the designer most of the time.
Much, much easier to design data templates (or create new ones based on an existing one)
Encourages you to write clear separation between your View and ViewModels – design the former in Blend, the latter in VS.
Easier to use behaviours – Blend has a built in repository of them so you can just drag them on. No faffing around with manually entering the namespace in your XAML etc.
Data Binding is quicker and easier to achieve – including use of converters etc..
Load the solution in VS 2010 on one monitor
Load the same solution in Blend on another monitor
Code my data models, services, and view models in VS 2010 with CodeRush etc. etc..
Build the project in VS
Switch to Blend. It automatically picks up any changes to the View Model.
Author the View in Blend
Save the View xaml file (not build – just save it)
Compile the solution in VS2010 (which picks up the amended .xaml file automatically)
I’ll stop there, suffice it to say that for most day-to-day tasks, it’s a much more pleasurable experience (or less painful perhaps?) in Blend. There are a few things that I’m still struggling with, such as how to effectively generate fake data to test out my views, and also how to get better control of how your view model is created – I like using Unity to create my View Models (typically as a dependency setter on the View’s code-behind) but if you create your View Model in Blend as a static resource, you can’t really do this.
I have to say that I’ve been really pleased with using Blend, so much so that it’s now become my default environment for XAML authoring. The best part of it is how seamlessly it integrates with standard VS2010 workflow, which now goes something like this: -
- It doesn’t sound much but I’ve found it to actually be a really compelling way to work.
I still use VS2010 – it’s still a powerful development environment where I can quickly knock up code-based elements of my solution (especially with good old CodeRush) – but for designing views, Blend now has my full support. We’re often no longer writing simple WinForms that perform simple data binding with a couple of buttons and a listview. We’re now writing applications that have custom chromes, complex data binding with converters, asynchronous service calls with busy indicators, data templating etc. etc. – perhaps this is as good a time as any to treat VS as a code-first tool, and leave the UI design to Blend.
I saw a couple of interesting discussions on LinkedIn this week with a few people discussing the merits / costs of using one of the XAML-based .NET frameworks compared to either WinForms or ASP .NET. Now, I’m somewhat reticent to compare SL to ASP .NET / HTML etc. as the two (to my mind) aren’t direct competitors. But WinForms and WPF, to me, seem like two technologies that are competing for the same space, with WPF destined to replace WinForms in the medium term; obviously since it came out it appears like it hasn’t been widely adopted, but I think this year we’ll see a larger uptake in WPF adoption particularly, for a number of reasons: -
Wider adoption by third-party component suppliers. DevExpress, Infragistics, DevComponents, RAD etc. are all shipping slick-looking WPF components such as gauges, grids, navigation panels.
Improved developer experience in Visual Studio 2010. VS2010 has better design time support now, which means that if you come from a WinForms background you should find the mental hurdle of writing forms in XML less so.
Anyway, my main point if really about this: Which of the following do you see WPF as being used for? Either: -
Graphically intensive applications e.g. 3-D animation, animations etc.
Line of business (LOB) applications – primarily data capture over a domain model sourced from a database, with validation etc.
Financial applications – graphs, some data capture, real time ticker feeds etc.
Believe it or not, the answer is – all three! The main point for this article is this: I was surprised when I realised that a lot of people see WinForms as the preferred platform for writing LOB applications, despite the fact that WinForms offers very little over WPF now, whereas WPF offers some really compelling reasons for such an application, such as the awesome data-binding or the much more powerful control over behaviour and look of your controls e.g. listboxes in WinForms were effectively useless for direct binding whereas in WPF they’re actually very useful thanks to data templates.
I also see people that believe that if you are writing a WPF application, it must use fancy animation, or worse still, that that is the only time that you should use WPF. Or that you cannot use WPF without being an expert in Blend. I’d disagree with all of these points! Whether you’re using WPF or WinForms shouldn’t affect whether you need animation in your application – is it a requirement? Then the technology choice is irrelevant! Do you need to do complex animation / styling? Then probably use Blend. If you just want to writing a simple LOB application (where perhaps the styling is not a core requirement) then don’t bother! I guess the upshot of this rant is this:
Don’t judge a technology only by what new features it brings to the table. Judge it by everything that you can do with it.
I personally see WPF as a full on replacement for WinForms, and encourage you to think of it as such, too. And if you want to get into it but don’t know how, I would suggest this. The next time you need to write a little in-house application to help you out in your day-to-day tasks, or write a tool to e.g. configure your main application to give to administrators/end-users – write in in WPF. Start small, with low-risk applications and solutions. Build up your knowledge of what it does and how it works slowly, but surely.
I’ve been looking into the Prism framework that came out of the Patterns and Practices team – if you’ve not heard of the framework, it’s basically the WPF and Silverlight version of Smart Client Software Factory. And if you’ve not heard of that – well, it’s a framework and set of guidance packages to write modular, decoupled and extensible applications i.e. any application that you expect to have a medium-long shelf life with changes throughout it’s lifespan.
I’ve had a relatively short look at it but expect to be spending more time with it over the next few weeks and months. So far, it looks like it addresses a number of the shortcomings of SCSF, such as the lack of flexibility with the framework in terms of IoC container (which was pretty much fixed to object builder in SCSF) and a clearer set of services and interfaces. It also allows you more control in terms of how you register modules within the shell than SCSF.
Generally, so far it seems more lightweight and easier to access than SCSF, although it retains many of the concepts. As I touched on before, it can use any IoC container that you want, although by default it uses Unity – which suits me fine as I really like that.
One thing I’ve not seen a decent answer on yet is how to register regions (think workspaces) into a modal dialog; in SCSF you had a modal dialog workspace which popped up a window automatically when you did a ShowViewInWorkspace – not seen anything like that in Prism yet.
There are a good set of videos on the net on Prism; I’ve been going through good old Mike Taulty’s series on Channel9 recently, and I’d recommend that if you want a good start in Prism. In particular, the first video is an excellent introduction if you have never thought about how to write decoupled and extensible applications using principles like SRP and the like.
I’ve been looking at Silverlight 3 (SL3) lately and seen some of the data editing features of it – really, really impressed with it. SL3 comes with lots of great-looking controls such as: -
Calendar, Date and Time Pickers
Auto Complete boxes
It’s actually getting to the stage where Silverlight is in some ways appearing to be a more compelling choice than WPF as a way to write rich UIs, since the control set has become that much richer. Anyway, the two controls that I was most interested in were the Data Form and the Data Grid controls – two controls that for any LOB and data capture you’ll want to be using…
This is a generic control to edit the fields of a particular entity. It supports change tracking, paging / record navigation, validation, and tooltips. Here is a simple Employee entity:
To edit this entity in the Data Form, drag on a DataForm and set the ItemSource property in code: -
Here’s the (slightly simplified) XAML. I’ve just removed some of the initialisation XAML but the Grid area is the bit we are interested in and it’s completely unchanged.
And here’s the code for the UserControl_Loaded event. I’m creating some “fake” employees and then binding that to the grid.
Here’s what we get when we run our app:
We can now edit any of the properties and the control has automatically bound them to the underlying datasource. Notice also the record browser at the top right of the form. By clicking the + button, the control will automatically create a new entity and add it to the ItemSource; similarly hitting the – button will remove the entity.
Here I’ve hit the “+” button to create a new entity. Pressing OK pushes the new entity into the collection, Cancel drops it. Also remember that this form is being dynamically generating based on the entity’s public properties.
The data form control can also do much more than basic editing of data. By decorating our entity with certain attributes, the control will do: -
Here’s a revised version of the Employee entity: -
I’ve now put a few attributes on some of the fields; by now re-running my code, without any change to the data form, I get this:
Notice that: -
The first field now takes the “Name” parameter on the Display attribute
The first field is shown in bold to indicate that it is Required.
The third field has a grey background to indicate that it is read-only.
The first field has an “i” icon next to it. Hovering over it displays a tooltip:
If you fail the validation on any of the fields, when trying to leave that record you get the following:
Clicking on any of the errors sets the cursor focus to the field in question. I am pretty sure that you can control the styling of all of this through XAML, but the default look and feel seems pretty OK to me. This validation will also kick in automatically if you e.g. enter a string into a integer field.
More control over editing
You can also set a few properties on the control to specify whether editing and committing of changes happens implicitly (as above) or explictly (see below). When you are explicitly editing data, you first have to the hit the “Edit” button in the record navigator to edit the record in view; then you hit the OK button (which only appears in Edit mode) to persist your changes.
You’ll notice in the last screenshot that there is no Cancel button. That’s because your entity does not track what it’s been changed to. But you can fix this by implementing IEditableObject on your entity; I’ve done it on my Employee class below:
All I’m doing in the above code is making a copy of the object as soon as you BeginEdit. If CancelEdit is called, I revert back to the old version of the entity, otherwise if EndEdit is called I remove the backup copy. Now when we edit any entities we get a Cancel button, too! This obviously calls CancelEdit above, whereas OK calls EndEdit.
DataForm looks like it’s a very powerful control that will save us lots of time when editing basic data on an entity. Because it has inbuilt support for validation (with support for RegEx as well) and change tracking, it’s something that could be of real use with LOB applications.