10% of your code is so complex it demands a strongly defined domain model. This project trivialises the 90%

DynamicBinder

I've just put a project up onto BitBucket for removing the cruft and noise from simple CRUD layers.

The use case is that you would have data of some sort coming from somewhere - imagine JSON data coming out of a WCF service - and you just want to bind some XAML to that data to show it on a screen.

Typically, what value does a ViewModel offer? It helps us interact with our domain model. We create public properties that simply wrap the exact same properties from our model. If there is some extra work for the screen to do between the user and the domain, then a rich ViewModel is a great place to do that work, but if there is no need then what a waste of time and effort!

In its absolute simplest form, imagine if your ViewModel looked like this

public FooViewModel : NotifyingDynamicObject { }

and the properties just get added as needed at runtime...

Now imagine that the shape of your Foo object subtly changes - say a field goes in or out - Just update your XAML and you're done. No updates to mappings; no need to regenerate layers; no need to manually add properties to 'placeholder' models or viewmodels.

I, for one, rather like that idea.

dynamic binding XAML
Posted by: Ian Randall
Last revised: 13 May, 2011 02:11 a.m.

Comments

No comments yet. Be the first!

Your Comments

Used for your gravatar. Not required. Will not be public.
Posting code? Indent it by four spaces to make it look nice. Learn more about Markdown.

Preview