Originally posted by allo
Question : how does one go about implementing such bindings without having to repeatedly move elements between relation collections and externally declared EntityList<T>-s? |
Navigation properties generated by the DevForce EF object Mapper are currently typed as IList<T>, although in fact what you are being returned is a RelatedEntityList<T>, and the returned list can be cast as such. In the future we may change these to return a RelatedEntityList<T> directly. (First we have to solve a problem or two that arises when related entity lists are returned in an anonymous type via a LINQ query.)
Whatever type we return when you reference a navigation collection property, it won't (at least by default) implement INotifyCollectionChanged, because that interface is defined in the WindowsBase assembly, which is all about WPF, which is, of course, all about the presentation layer of an application, not the business model. Microsoft has worked hard to keep these layers separate, and so have we. A developer building an application with a DevForce EF persistence layer and a WinForm user interface might well wonder why he needs a reference to an assembly designed for WPF support!
On the other hand, it is likely that whatever list we return will provide notification of changes in some form, possibly through implementation of IBindingList<T>. That seems to provide the same notification functionality that INotifyCollectionChanged does, except that it has the advantage of being recognized by Winforms data binding as well as WPF data binding. See this discussion from Rocky Lhotka:
The best you can do meanwhile might be just to tell the control, when you update the list, to refresh itself. You can find discussions of that by googling "refresh wpf binding". E.g.,
Pretty sure we'll have a better solution for you in the next release.