Goblincave

I am reading up on usability at the moment and I passed a usability guru’s website – Jacob Jensen. He has strong opinions – and I like strong opinions and tend to agree with him mostly. Well, that’s up until now – I read an article by him entitled “Google makes you dumber” (link). That [...]

Sometimes, I’m wondering whether anyone is actually reading my posts here at GoblinCave. I realize that many will stop by only once or twice when a google search has turned this way – but I have no idea if there is an audience for the posts I’m writing. So, a quick raise of hands (read: [...]

I’ve saved the goodies for the last post. We are now ready to edit an order after post 9 – and we want to do it in style. We want to present the user with a really nice interface for fast input. We could have done it the old-fashioned way with an ‘Add’ button for adding an orderline in a new window, but hey, we got a shiny ‘new’ DataGrid in 4.0 – so let’s put that for a spin:

We are now turning towards a somewhat more involved example after a little break in part 8 – the orders. We’ll make a bit more complex filter for the list of orders while keeping it paged – the IOrdersViewModel is so akin to ICustomersViewModel that I’ll jump to the differences in the IOrderFilter:

Okay, we have successfully created a small application in part 7 where the user can add, edit and remove customers. Not bad considering the small amount of code in the solution. Still we have a lot of classes involved and this alone creates a lot of complexity. We are paying the price for a very stable and easy-to-maintain solution down the road. I hope this will be easy to see when we start implementing entity number two – the order.

Okay – part 6 was ViewModels – now it is time for the eye-candy and unleashing the power of the ViewModels. All views (save one) will implement the IView<TViewModel> interface which has a single method: void SetViewModel(TViewModel viewmodel). I’ll explain later why there are no more methods…

Okay – so in post 5 we have managed to get and find data – now we need to be able to perform interactions with the data. We need an implementation of interface ICustomerDetailViewModel:

We introduced commanding in part 4 and so far we have mostly been trying to get to the point where we can actually see something on the screen – and now we will look at the data behind the view. Enter the ViewModel. The responsebility of the ViewModel (in my version, at least) is to act as a mediator between the (dumb) View and the Model.

After part 3, we are getting ready to tie things together and as many might know, WPF contains the really nice ICommand interface that implements well with buttons, menus and inputbindings (go .Net 4.0). Back when I started out with WPF I used a lot of standalone implementations of the ICommand interface. It made for very nicely encapsulated commands, but there were problems. I put them into ResourceDictionaries for sharing them between views, but soon I had an overwhelming number of them, and naming became a problem. Also, maintainability proved troublesome. Having scattered business-logic scattered out into all these little classes that I couldn’t use DI (Dependency Injection) on proved a maintenance nightmare and ResourceDictionaries proved brittle (magic strings, anyone?). Testability wasn’t all that great either, and most of the commands were mostly doing boxing and un-boxing and IoC (Inversion of Control) resolution.

After part 2 – we now have a model to work from – and it is time to create the first ViewModel.

After some carefull consideration – I’ve chosen that we need a list of Customers where we can perform CRUD (Create, Read, Update, Delete), to make things a bit interesting, we want to have a paged view as we expect our customers to range in the thousands