Heavyweight properties

krevak posted on Tuesday, September 25, 2007

Hi

I am just investigating CSLA and am quite impressed. 

One of the things that bothers me though is the redundant code necessary in the business object property set/get. (eg CanRead, CanWrite, PropertyChanged)  Is it possible to use classes instead of base types as the properties and still have them bound to the db and UI? 

My reasoning is that that will allow you to have much smarter business objects.  SmartDates are in the same mindspace.  In the example I seen (dnrTv), the BO uses a SmartDate internally but exposes a string property to manage the UI set/get of the date.  Seems to me that you would then need to expose another property  to handle get/set as a date.  Would it not be better to have a DateProperty class that exposes a Value that is of type date and has a UIString that handles conversion to/from strings?  The CanRead/CanWrite/PropertyChanged logic would only need to be implemented in the DateProperty class and not in every BO that uses it.  There is of course a whole whack of other intelligence that the DateProperty class could implement.

Code generators are sometimes suggested but they just allow one to generate more redundant code faster and would clutter up the BO namespace with DateAsUIString and DateAsDate properties.

 

 

 

 

 

 

RockfordLhotka replied on Wednesday, October 03, 2007

You are right, it would be nicer to expose the properties as a more complex type that could not only provide the property value, but also metadata and other functions around that property.

Unfortunately, data binding doesn't work with that model. So following that model means abandoning data binding - or coming up with some abstraction layer that would sit between data binding and your objects.

krevak replied on Wednesday, October 03, 2007

I have had some luck implementing ICustomTypeDescriptor, PropertyDescriptor, ITypedList (and soon IBindignList).  It seems to work okay at run time but I have having little luck at design time (ASP.NET).  Am not sure if I want to keep persuing this angle or give up and use vanilla business objects.

Ken

 

tetranz replied on Wednesday, October 03, 2007

I assume you're talking about two way databinding. Maybe I'm stating the obvious but, for what its worth, databinding seems to work just fine in the readonly direction for complex properties.

Lets say I have an Order BO with a CustomerId property then within Order I often have a CustomerInfo object which is exposed as a property called CustomerInfo, usually with lazy loading. CustomerInfo is just a simple object which is not much more than a tidy way of grouping my borrowed fields such as CustomerName, CustomerType etc. I sometimes have an observer pattern that updates CustomerInfo if a real Customer BO is saved elsewhere in the app.

Anyway ... there is no problem binding a Textbox to Order.CustomerInfo.Name.  Visual Studio only shows CustomerInfo when I pick from properties of Order but then I manually append .Name to the end.

Ross

RockfordLhotka:

You are right, it would be nicer to expose the properties as a more complex type that could not only provide the property value, but also metadata and other functions around that property.

Unfortunately, data binding doesn't work with that model. So following that model means abandoning data binding - or coming up with some abstraction layer that would sit between data binding and your objects.

RockfordLhotka replied on Wednesday, October 03, 2007