Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I am evaluating the work needed to upgrade an app using CSLA.NET 3.0.x to CSLA 3.8.x or even 4.3.x.
Our app includes "smart" data classes (SmartBoolean, SmartDecimal, SmartString, etc.) that contain state and include BusinessBase in their inheritance chain.
Our typical property setters and getters include lines like "return myBackingField.Value" and "myBackingField.Value = value".
In reviewing how the framework handles coercion with SmartDate, I see that conversions from the "smart" type to a DateTime will use the TypeConverter class for the SmartDate class. However, conversions from a DateTime to a SmartDate do not use the TypeConverter. The CoerceValue method has special code that results in using the existing SmartDate instance and updating the internal value.
I would like to have that same behavior for my "smart" classes. I would not want my property setter to create a new instance of my Smart class. Instead, I would prefer it to update the existing instance. I am having trouble with where I could implement this without changing the CSLA source code.
Am I going to have change the CSLA source to handle my custom types in the same fashion as the SmartDate?
Yes, you need to change the CSLA code to do that.
You may do this quite "generic" by using the ISmartField interrface (assuming your smart fields implement ISmartField).
Jonny Bekkum, Norway CslaContrib Coordinator