I am wondering if these days the done thing is not to bind the output of an ORM directly to the controls in the UI, but rather to have an intermediary part of the UI between the ORM output and the controls
Both EF4 books I have mention this and hint that binding to entities or passing them over service boundaries is not a good practice. For small apps or maintenance utilities (I'm writing one now), editing entities directly doesn't worry me, but when you start passing them over WCF or Remoting then I'd consider using DTOs (Data Transfer Objects) that are custom views of the entities. However, you then have to write more infrastructure to move them around. Is this what model view presenter / model view controller / model view view controller are about? MVP/MVC/MVVC ? Kirsten Those patterns solve a different problem. Your sample code where you bind the query results to a grid is fine for small apps, but as you scale-up and have tiers, then it's impractical. Nathan, I generally agree with your comments, but you need to write so much more infrastructure. However, I'm still stuck with the limitations of the features implemented by EF4 entities and collections. As a comparison, I looked at some netTiers output classes and I challenge anyone to casually knock-up classes that implements it's interfaces: Generic Collection ListBase<T> : BindingList<T>, IBindingListView, IBindingList, IList, ICloneable, ICloneableEx, IListSource, ITypedList, IDisposable, IComponent, IRaiseItemChangedEvents, IDeserializationCallback Sample Entity FooBase : EntityBase, IMedia, IEntityId<MediaKey>, System.IComparable, System.ICloneable, ICloneableEx, IEditableObject, IComponent, INotifyPropertyChanged The System.Data classes implement most of these as well and that's why I find them so convenient. Greg
