Stephen, we are definitely in agreement here. Your point about making the solution UI-neutral is a great one. And in fact the idea I already have in mind, to include my OnCollectionChanged() method, is in fact UI-neutral. In my original post I just offered to take it one step further by also implementing INotifyCollectionChanged. But if that isn't UI-neutral then I will gladly accept refraining from taking it that far.
On Nov 26, 10:03 pm, "Stephen Bohlen" <[EMAIL PROTECTED]> wrote: > 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 > >
