Creating a client side UI friendly data model... RRS feed

  • Question

  • Hello,

    the underlying implementation of my POCO(I think they are?) EF classes uses ICollection, for associations (I note that the EF team has implemented "Local" on DbSet<T> to return an ObservableCollection to keep UI builders happy BUT there seems to be no equivalent implemention on assocatiations).

    ICollection<T>s bind as fixed length (you can't add/remove entities) to WPF controls....which is a massive pain (I think because of the constructors of ObservableCollection<T>)

    I CAN write an adapter to make ICollection<T> and ObservableCollection<T> (at least it seems to work).

    So if I can extend or decorate the underlying data model I can bind directly to it, and not have to write lots of boilerplate.

    I tried unsuccessfully to do this with delegation...i.e. decorate the underlying model, but it was a complete pain.

    I tried to inherit from the underlying data model....but I cant seem to get his to work....I don't understand enough of the EF magic to get this to work.

    I have successfully extented the partial classes in the class library to expose their associations as ObservableCollection<T>....this works! far!....but I feel

    a) it should be on the client

    b) how are other people doing this? (is everyone mindless copying stuff to Lists and then binding to the Lists and then writing code to detect changes?...this seems madness?

    Really (putting MVVM to one side)...we want to go


    ViewAdapter (VM?)....but this should be little more than a set of references to .....

    UI data model...this is almost exactly the same the the underlying data model (so in fact inherenting from the underlying DM seems reasonable).

    EF data model...

    Tuesday, October 2, 2012 3:40 PM


All replies