Building BOs of CSLA to support dynamic amount of fields, field names and field types - help!?

ianinspain posted on Friday, February 16, 2007

Hi there,

I am currently trying to implement a business object using csla but with a twist, i really am lost and would appreciate any input. If anyone can jump please feel free and would love to hear Rocky's view on this

Basically 1 BO's is going to be editableBase for a holding information about a House / Property.. But i took it 1 step further and decided to allow the clients/admin of the system to create dynamic fields with dynamic types... ermmm let me explain..

standard set of fields = Plot size, Build Size, No. of Beds, No. of Baths etc

Then if the admin needs to be able to add more fields to the app (which will use the business object) then he/she could say:

Field name : Has Garage
Field Type: Boolean
Default : false

and

Field Name: Mobile Telehone Number
Field Type: string
Field Size : 15

In theory its a great idea ( in my opinion!) and its just want i want but i am lost to how i would create the BO's because they are not static... I would need to store these in a db which the BO would need to retrieve and give the developer access to each field...

I suppose i could have a method to say RetrieveFields and a property to say Count (amount of fields).. the retrieve fields would return a collection class that would have the properties of the field i.e. name, size, type etc etc

Then i suppose to get information into and out the the field i could use an indexer on the BO although i think this is pretty lame... any additional ideas?

The other problem i am having is that i would have to store this information into the db, i wouldn't want to create additional fields in the db for each dynamic field so what would be the best way of doing this, i was think of storing the information into a BLOB or something as its binary so technically supports all types of info or failing that (although i haven't looked into yet) into a XML field type of a SQL Server as i suppose i can store properties along with the details..

As you can see i have a vision but really need some input from people to get it off the ground..

I hope someone can help!

Thnaks

ian

mr_lasseter replied on Friday, February 16, 2007

For the database, one solution is to create 2 tables for your objects.  The first table will be your main table which will have your common attributes. Something along the lines of::

T_LISTINGS
listing_id  (PK)
plot_size
no_beds
no_baths
...

Then create another table like so
T_LISTINGS_EXTRA_INFO
listing_id (PK)
property_name (PK)
value

Now you can add as many addtional properties to the Extra Info table as you would like for each listing.  You could add an another table that keeps track of the valid properties so users can't go crazy with this but that is up to you. 

As for your BO, I think you are on the right track.  The only thing with this solution is you lose the databinding and the validtion rules for the additional properties.  Although, I am sure you could modify the validation rules to work with the additional properties if you needed to.

Hope this helps.
Mike