Dynamic Properties

[cwer...@gmail.com]

I have a question regarding dynamic properties.

I have an Object say

Account
--Id
--Prefix
--Fname
--Lname
--Suffix
--RecordType

This is in a Application Service Provider Model, so say Client 1 has
only those properties available for account.

NOW Client 2 has some additional requirments

That may look like so

Account
--Id
--Prefix
--Fname
--Lname
--Suffix
--RecordType
--Entity
--ParentId
--LastContactDate

The Third Client may have these requrments

Account
--Id
--Prefix
--Fname
--Lname
--Suffix
--RecordType
--Source
--HairColor

I am using .Net 2.0 with SQL 2005 for the Data, and DAAB for the DAL,
but IBatis or NHibernate are also options, and I am familiar with the
usage of both.

All of the above are the same through Suffix, but I would like to be
able to dynamically assign properties to these objects, the DAL can
support it so there is no problem there.

ON the interface layer I dont have a problem dealing with these, so no
problem there , my question is at the object level what is the most
EFFICIENT way to deal with these ?

What is the best (or any way and I can decide later) the best
implementation of allowing a "Per Client" config of properties on
several core objects, say Account, Transactions, Orders, Contacts, etc
?

I have several working possibilities, but quite frankly would like
some feedback before I implment this in production, some of the
solutions I have seem a little heavy handed.

I am seeking feedback on options I may not have sen, thought of or
pursued.

Thanks

Chris

[GhostInAK]

Hello cwer...@gmail.com,

Three methods come to mind at once.

1. A base object that implements all the common fields plus one property
(lets call it .ClientExtensions). Then, for each client, build a new object
that you can assign to .ClientExtensions. Then use reflection (or the database)
to figure out whats in them.

2. Build your object assembly for each client dynamicly using System.Reflection.Emit
namespace. This is the method the company I work for has chosen for one
of our projects. It works quite well, but it takes a LOT of development
time to get the object/database interactions correct. And the flexibility
benefit is lost between the additional dev time and the intollerence for
mistakes in data entry (since the database basicly controls the object model).

3. Add a .Properties proeprty to your base object which is a Hashtable or
keyed Collection. Then you can just access values via key name.

-Boo

[cwer...@gmail.com]

Thanks, I was pretty much on the same path as number 2 but I have to
agree thats what I have seen thus far with its limitations. I want to
make this as simple of an extension as possible.

On that note could you elaborate a little more on the first option ?
I am 90% sure I know what you are saying but I must be missing a little
something.

Thanks

Chris

[GhostInAK]

Hello cwer...@gmail.com,

>> 1. A base object that implements all the common fields plus one
>> property
>> (lets call it .ClientExtensions). Then, for each client, build a new
>> object
>> that you can assign to .ClientExtensions. Then use reflection (or
>> the database)
>> to figure out whats in them.
>> 2. Build your object assembly for each client dynamicly using
>> System.Reflection.Emit
>> namespace.

#1 is a hybrid of #2. You would code up a static library (DLL) that contained
your class. Then build a database model into which you will store the definitions
of each client's proprietary properties. Upon change of a client's definition
of their properties, build a dynamic DLL (using System.Reflection.Emit namespace).

Your class in the static library would contain all the shared properties
plus any common actions that may take place on the data as well as a property
(lets call it .ClientExtensions for now). This .ClientExtensions property
would accept any object. At runtime you create an instance of the dynamic
client class and an instance of the static class.. you assign the dynamic
object to the static's .ClientExtensions property.

I gotta say, option #3 (just using a hashtable) seems like much much less
work, is extensible, and provides a much higher return on investment.

-Boo

[cwer...@gmail.com]

Im going to have to agree......

It just seem, I dono unclean for some reason.....

Oh well, thanks much for your input.

Chris

[GhostInAK]

Hello cwer...@gmail.com,

Of the options presented it's not terribly unclean. You lose intellisense
at design time.. but then, you prolly wont be coding against the client-specific
property values at design-time anyhow. You lose strong-typedness.. but VB's
late-binding will take care of that. It's really not a bad option.

-Boo