> 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
>

> Hello cwert***@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
>
>
>
> > 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
> >

> Hello cwert***@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

> Im going to have to agree......
>
> It just seem, I dono unclean for some reason.....
>
> Oh well, thanks much for your input.
>
> Chris
>
> GhostInAK wrote:
>
>> Hello cwert***@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
>>