WPF Databinding best practices/examples?

HI,

I recenty had a debate with some fellow developers about Lightspeed, and there seems to be general (and widespread) confusion (misunderstanding?) regarding the best way to make data available for databinding (ie. Wpf Grids or Listboxes via the ItemsSource/Datasource properties) with particular emphasis on how best to make the data available outside of the shortlived UnitOfWork and what the recommended practice's for this are?

There was a previous post on the 24th of Oct where it was mentioned that a WPF example may be forthcoming, any progress on this?

Thanks

Leon

There are two basic approaches to this, and the right one will depend on your application design.

1. Long-lived unit of work (e.g. per-screen, or even application lifetime).  In this case you can just bind to the entities, modify them as required, and save them back whenever appropriate.  This is obviously very easy to work with, but if other users are modifying the data at the same time then it can become stale.  Another benefit is that in this case LightSpeed handles pending changes for you.

2. Short-lived unit of work (just long enough to load or save entities).  Entities continue to be usable even after their unit of work has gone away; you will just need to re-attach them to a new unit of work if you want to save them (see IUnitOfWork.Attach).  This requires a bit more management, but whether this will be a problem depends on the exact structure of your application.

For example, suppose you have an app which displays a list of entities, and allows the user to add, delete or edit entities.  You could load the entity list in a short-lived UOW.  Then if the user clicks New, create a new entity, let them edit it, and when they click OK, create a new UOW, add the new entity, and save changes.  If the user clicks Delete, attach the selected entity to a new UOW, delete it, and save changes.  If the user clicks Edit, display the screen (you might even reload the entity in a new UOW to ensure the data is fresh), make the changes, and when the user clicks OK, create a new UOW, attach the modified entity to it and save changes.

But if the user wants to make a bunch of changes, including multiple adds, deletes and edits, then save them all in one go at a later point, things get a bit more complicated.  You end up taking a greater share of responsibility for tracking these entities, so that when you create a new UOW, you know what to attach to it.  You can partly handle this by re-attaching the entire object graph to the new UOW, but this won't work well with deletes.  In this case, the long-lived UOW is more appropriate.  (And hopefully you wouldn't design an app this way if multiple users were modifying the data at the same time, because that would give you all sorts of reconciliation issues.)

So really what it comes down to is figuring out what the unit of work is at the user level.  Do users perform long series of operations and then commit?  Or does the application commit as it goes, with little pending state held in the UI at any time?  The lifespan of the IUnitOfWork should reflect the granularity of saves in the application design.  Our "two approaches" really live on a continuum and reflect the business logic of commits and the desired user experience.

None of this really answers your question about WPF data binding, but once you have an entity or a collection of entities, the binding stuff should really fall out automatically, regardless of how long- or short-lived your units of work are.  I think the main difference would be that if you use short-lived units of work you may need to write a bit more procedural code to handle attaching entities in order to save them.  If you've got specific questions then please post them and we'll try to answer them.  Similarly if you need more specific guidance on UOW granularity / lifespan.

Unfortunately we have not managed to progress the promised WPF sample, due to an external project which is consuming a lot of our resources at the moment.  We're sorry about this and will try to get back to it soon.