Actually, if you look really closely you will see that... 1) yes, .NET 3.5 supports these interfaces for change notification 2) under 3.5 there are DIFFERENT notification interfaces that you need to implement to properly participate in WPF than in winforms (the source of my statement that several of these are 'UI specific'
If you are building your own UI in a technology of your own design, then you can choose which of the notification interfaces you are interested in implementing in your objects and (presumably) your own UI technology would be able to similarly 'choose' which of these events to subscribe to. But if you are choosing WPF vs. WinForms, you DO have a different set of interfaces that your objects must implement in order to 'participate' in the rest of the UI environment that you have chosen. If you look very closely at the docs (even for 3.5) you will actually see that while (of course) all of these interfaces are in the end 'just .NET 3.5 interfaces', the ones your objects need to implement actually DO change depending on which UI platform you are targeting with them. Again, I direct you to Rocky's latest CSLA treatise where he explores at length the (subtle) differences between the change-event-notification models in WPF, winforms, and even Silverlight. Without getting of on a wild tangent here, I would just restate my opinion that the answer (in my mind) is to ensure that the right extensibility points and overridable behaviours are provided for so that anyone can intercept and wire up any specific needed eventing points as they might need to support ANY change-notification-model they my see fit to choose (which, I think, is sort of what you were advocating in the first place, no?) On Wed, Nov 26, 2008 at 9:54 AM, HappyNomad <[EMAIL PROTECTED]> wrote: > > I would like to point out that NH 2.1 itself targets .NET 3.5. And > INotifyCollectionChanged is part of .NET 3.5. INotifyPropertyChanged > and INotifyCollectionChanged is a general mechanism in .NET for making > objects observable. It is NOT part of a "specific UI model". Sure, > WPF uses these interfaces, but it could be used for other GUI > frameworks as well. It could even be used for non-GUI frameworks > which observe the domain model. > > In any case, the bare minimum I am asking at the moment is add this > template method to AbstractPersistentCollection: > protected abstract void OnCollectionChanged > ( NotifyCollectionChangedAction action, object changedItem, int > index ); > and then call it from all of its subclasses, whenever the collection's > contents are modified. This wouldn't be adding observability per se > (although it's not far from it I admit). > > > On Nov 26, 9:33 pm, "Gustavo Ringel" <[EMAIL PROTECTED]> wrote: > > I think the task of the persistence layer is not to be bindable to an > > specific UI model...or to inform about something to an specific UI model. > > So for sure it is not part of the core. > > It may be an extension to put in the contributions... > > > > Gustavo. > > > > On Wed, Nov 26, 2008 at 4:29 PM, Fabio Maulo <[EMAIL PROTECTED]> > wrote: > > > 2008/11/26 HappyNomad <[EMAIL PROTECTED]> > > > > >> NH 2.1 targets .NET 3.5, and > > >> observability is a fundamental feature of .NET 3.x, so I think the > > >> best way to solve this problem is to incorporate observability into > > >> the NH core. > > > > > Sure... and sure we will add INotifyProperyChanged, and a base class to > > > work with lazy-loading and INotifyCollectionChanged and probably > > > IBindingList implementation. > > > Be sure about that. > > > -- > > > Fabio Maulo > > > > >
