One thing I haven't understood in CSLA is the code to add and remove listeners to the framework events where the attribute "NonSerialized" of the listeners is checked and, if the listener is serializable, it is added to a serializable handler. Why would somebody wish to serialize all the listeners to an event that the object being serialized raises? Why not have only nonserializable event handlers variables?
In .NET 1.x the BinaryFormatter had some promise to serialize events and/or the objects that handled events. At that time the workarounds to prevent event reference serialization were really awkward and I had long conversations with members of the CLR team that owned serialization.
Based on what I knew then (remember, around 10 years ago or more now), the strategy I followed seemed to be the best approach.
Today I agree with you, and you'll notice that several newer events simply have nonserializable backing fields for the events. Only the older event declarations from way back when use the older technique of two backing fields.
You could argue that I should go clean up that old code.
Of course you can also argue that code that's known to work and be stable for 7-12 years shouldn't be touched, because it would be silly to change such code just for aesthetics.
Thus far I've opted for the second viewpoint.
That's not least because I also think you could argue that the code to support WinForms 1.x data binding isn't needed anymore either. And that some of the DataSet support is not very meaningful. And a handful of other 'features' of CSLA that were relevant in 2002 just don't matter now.
On the flip side, all that code is known to be stable and has been unchanged for a decade or so. My general feeling is that I'll get rid of all that stuff when I drop support for Windows Forms - and (for better or worse) that's not likely to happen any time soon :)
Thanks, Rocky.
Copyright (c) Marimer LLC