By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,293 Members | 1,397 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,293 IT Pros & Developers. It's quick & easy.

Dynamic Properties ?

P: n/a
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

Jul 24 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Hi Chris,

Please clarify 'dynamic'. I'll assume two possible scenarios:

1. Several well-known client requirements differ from each other at design-time.

If several clients each require some properties on the Account object that are similar and some that are different, as you
mentioned, you might try using inheritance. Inheritance is useful regardless of whether client requirements are determined early on
or late in a project's development as long as you create a scalable foundation. Create an abstract BaseAccount class with all of
the shared properties such as Id, Prefix, Fname, Lname, Suffix and RecordType and derive classes on a per-client basis. Add
client-specific properties to each client-specific class. From this basic design pattern you can expand out to others using
interfaces, for example, if you require a more scalable solution or if you need to distribute the objects using web services or
remoting.

2. Properties must be added at runtime.

Create a single Account class with the common properties and one extra Dictionary<string, objectproperty for extensibility at
runtime.

What are some of the solutions that you have come up with but are unsure of?

--
Dave Sexton

<cw******@gmail.comwrote in message news:11*********************@b28g2000cwb.googlegro ups.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

Jul 25 '06 #2

P: n/a
There is no way to spec these properties in advance, they are mostly
for simple storage at the DAL.

We may take on a new client tommorow that has 11 more things weve never
seen, and we need to be able to handle them from interface to DAL, as
well as the application of Business Logic ,

The business logic will (and is ) handled by a homegrown rule engine.

One other problem (and why I had interest in adding properites at
runtime is the depth ,

Say Hair may have Color, Texture and Length, etc, I can flatten them ,
but once again it seems unclean.

It is evolving into an AJAX interface on the presentation layer away
from WebFroms, and as such we have the ability in JavaScript to create
objects and add properties at runtime.

There are a couple of other methods I have looked into here

http://groups.google.com/group/micro...11a6b4b75b5dda

(the second listed in the thread, which falls in the same direction
you metioned)

I was thinking something I had missed, hoping it was the squeaky clean
solution I was looking for.

Just thinking out loud here........

Having each property defined as its own class, kinda a generic basket
of junk....
thats do-able...
then...

Something with Generics and maybe a Decorator model ?...

Or something of the ilk.

Or maybe something along the lines of a UDT in SQL 2005 defined at
runtime, then a collection of those ?....forget that one.... that make
mine look as clean as the driven snow.

Like I said I am looking for suggestions, Ill be the first to admit
while I know a lot and have seen a lot, I dont know everything and
havent seen everything....So I was looking for Ideas that may lead me
down the path to coding righetouness....

Thanks again

Chris
Dave Sexton wrote:
Hi Chris,

Please clarify 'dynamic'. I'll assume two possible scenarios:

1. Several well-known client requirements differ from each other at design-time.

If several clients each require some properties on the Account object that are similar and some that are different, as you
mentioned, you might try using inheritance. Inheritance is useful regardless of whether client requirements are determined early on
or late in a project's development as long as you create a scalable foundation. Create an abstract BaseAccount class with all of
the shared properties such as Id, Prefix, Fname, Lname, Suffix and RecordType and derive classes on a per-client basis. Add
client-specific properties to each client-specific class. From this basic design pattern you can expand out to others using
interfaces, for example, if you require a more scalable solution or if you need to distribute the objects using web services or
remoting.

2. Properties must be added at runtime.

Create a single Account class with the common properties and one extra Dictionary<string, objectproperty for extensibility at
runtime.

What are some of the solutions that you have come up with but are unsure of?

--
Dave Sexton

<cw******@gmail.comwrote in message news:11*********************@b28g2000cwb.googlegro ups.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
Jul 25 '06 #3

P: n/a
Hi Chris,
There is no way to spec these properties in advance, they are mostly
for simple storage at the DAL.
We may take on a new client tommorow that has 11 more things weve never
seen, and we need to be able to handle them from interface to DAL, as
well as the application of Business Logic ,
And the users add these 'properties' at runtime through a GUI? Something like name & value?

If so it sounds like a Dictionary of name/value pairs would do just fine. You could even serialize the pairs into the database but
that means you'd have to ensure that all of the data is serializable.

For a more OOP approach you could create an interface like IAccountExtension and maintain a collection of IAccountExtension
implementations in your Account class that could be added and deleted at runtime. IAccountExtension could implement ISerializable
for your data access needs. This idea is probably overkill for your particular problem and a Dictionary should do just fine.
One other problem (and why I had interest in adding properites at
runtime is the depth ,

Say Hair may have Color, Texture and Length, etc, I can flatten them ,
but once again it seems unclean.
Trying to code your app so that it can apply semantics to properties or relate them in a heirarchy at runtime would be time
consuming to say the least. Would that actually provide any value to the users of your application? I wouldn't recommend adding
that type of functionality unless your absolutely sure that it would add value, and it doesn't sound like you are.
It is evolving into an AJAX interface on the presentation layer away
from WebFroms, and as such we have the ability in JavaScript to create
objects and add properties at runtime.
I'm not so sure that coding some or all of your business objects in JavaScript is such a good idea. I wouldn't want to maintain
that application. It makes more sense to me if you were to collect the data and post back to update the database using server-side
business objects. AJAX would be ok if the users need to view a list of 100 or more extended properties and you want to save some
download time, IMO.
There are a couple of other methods I have looked into here

http://groups.google.com/group/micro...11a6b4b75b5dda

(the second listed in the thread, which falls in the same direction
you metioned)
Well, I didn't mention reflection or reflection emit and I'd strongly advise against each unless it's absolutely necessary.
Reflection emit doesn't provide anything that a Dictionary property wouldn't provide as well in this particular case. Reflection
emit would take a longer amount of time to code, it would be harder to code, harder to debug, harder to maintain, only comes with
performance, scalability and possibly security costs, among other issues you'd have to address.

[...]
Something with Generics and maybe a Decorator model ?...
Decorator pattern won't help you to add properties to an object at runtime. You would use this pattern to 'decorate' one class with
added functionality at design-time by creating a wrapper class that implements the same public interface.
Or maybe something along the lines of a UDT in SQL 2005 defined at
runtime, then a collection of those ?....forget that one.... that make
mine look as clean as the driven snow.
Sorry, I can't help you there.
Like I said I am looking for suggestions, Ill be the first to admit
while I know a lot and have seen a lot, I dont know everything and
havent seen everything....So I was looking for Ideas that may lead me
down the path to coding righetouness....
HTH

- Dave Sexton
Jul 25 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.