Choosing deisng pattern

Hi.
Your help is very appreciated.
I want to build an app that is basically a client db.

For that I am contructing a "client" class (that has - name, address, contact details etc...).

However, I want to enable my users, to add properties to my "client" class WITOUHT needing to change my code.
i.e. some clients might require an "age" and "annual income" properties as part of the "client" class.

Which design pattern(s) might assist me

p.s.
I would like to use .NET(C#) to implement it .

Thanks a lot
Roy

Answer this question

Choosing deisng pattern

DonOrel
I think you simply want a client table with generic information about each client, and then another table ClientProperties, which has columns for the property name, value, maybe datatype, and associated client ID. Downside is if you wanted to use the same property for several clients you would have to retype the property name. You could create a seperate table that lists property types and then refer to one of the types when assigning a property to a client. I don't really think this involves any special design patterns other than ones you would normally use. I hope that helps.
Rick9004
have you thought about not using a database, but XML instead
Klayman

Roy,

I'm not sure that I understand what you are asking. Are you saying that you want the UI to dynamically change upon the request of the user Would these new properties already exist in the database If you can elaborate one of us on the forum could more accurately make suggestions.

Tim Murphy
Elfreda

Take a look at the following paper : http://www.joeyoder.com/papers/patterns/Metadata/metadata.pdf for some related patterns

Arnon
Wolfgang Rockelein
Thanks Sergey.
1. One thing that this solution is missing is meta data on properties that are not part of the field's built-in db attributes (such as: null, default value, data type etc..).
I.e.
* What if I want to specify for each porperty "order" attribute (it will determine the order in the GUI) or
* inactive attribute (if user chose to 'get rid' of property that already has some values in it and I want to keep the data).
* What about parent-child / hierarchy relationship between properties

therefore, apart from the entities tables(customer, etc..) I can use "metadata" table which holds this data.

METADATA table
Property ID
Is Active
Order
Parent Property ID.

* Thanks for explaining about the "mark as answer" thing.
I feel that it might be unfair to unmark already marked answers now. I will do it for future posts.
Dave Anson
Hi Greg.
I read your linked post http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=274811&SiteID=1&mode=1 with great interest. After carefully thinking about solution, I came up with an idea - Id'e be interested to hear your opinion.

The requirements:
1.Allowing the user to dynamically add properties to entities (i.e. client, suppliers, staff, etc..) without ANY code or db modification.
2. Saving data-type information for every property (so validation checks can take place)(i.e. property 'Birth Date' for Entity 'Client' must not be null and must be a valid date).

Table structre that I'm suggesting:

Entities table holds for every entity (i.e. supplier, client) it's entity type . The entity type is a unique indentifier that allows me to get all the properties for this type from Properties For Entitities table.

Properties For Entitities describes all the properties for each type (it's many-to-many relationship between EntitiesTable and Properties Table.

Object Data table is the one that actually holds the data.

EntitiesTable

Ent ID (pk)

Ent Name

Ent Type(fk)

Entities Type

Ent-PK (pk)

Ent Name

Properties Table

Prop NAME (pk)

Prop Display Name

Prop Type

Prop IsRequired

Prop Default Value.

Properties For Entitities

Ent Type(fk)

Prop Name(fk)

Object Data

Ent ID(fk)

Obj PropertyName(fk)

Obj Preporty value

This design allows me to:

1. Dynamically add properties.
2. Having data-type and defualt value for each property (i.e. I can create dynamic validation checks in GUI)
However:
1. The code is a bit more complex.
2. Performance is not the fastest (can't use indexes efficiently).
3. Doesn't handle situation of heirarchical properties, or properites with Business Logic.

I hope I explained things clearly, if not please ask me.

Thanks again.
Roy
pedrojr

Why invent wheel SQL server has stored procedures to read DB model (such as sp_columns) and to alter DB scheme ("ALTER TABLE" SQL command). What is the reason to build wrapper over SQL to do SQL's native job

Also in .NET, DataSet class have schema inside it. You can add new columns to tables or remove them from there. In DataAdapter class there is MissingSchemaAction field that help to deal with new fields.

P.S. Roy-roy, you should mark 1 or 2 posts as answers, but not every post. This will help for people in future to find best answer on the question, without reading whole discussion.
Lionel Modi
A few weeks ago I wrote a very detailed response to a similar question regarding some of the issues that can come up http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=274811&SiteID=1&mode=1

The design pattern you are looking for on the code side is most likely "property bag" its the db side where things get a bit more interesting as reporting can become a complete nightmare ... I often recommend a dual methodology approach to minimize the cost on reporting.
Grace Uy
Hi!

All depends on level of complexity you ready to take. Here is choices:
1. Create 10 (or 100) string fields and allow user to name them
2. Work with database schema to declare new fields (programmatically add/remove columns)
3. Create 2 tables
Cool way is to extend schema, but it have some more work to than others. If you need more help - ask.
Rido

Yes, you get it right - when you develop database, you create columns in designer, when you want users to extend DB - let them make columns through your app. You can mark fields made by users with underscore or any other way, for example, user want to add BirthDate field to [Customer] table, so you extend DB with [Customer].[_BirthDate] field.

Users do get credits by answers, but this is not the goal. Goal is to mark best answer (or two answers) so in future when somebody will search forum for help, he will see answer faster. I think nobody will be very upset if you unmark them all for now and when your question solved, you will mark best answer or write resume by youself and mark it as answer. BTW, I'm changing thread name to better reflect your question, to make it more clear when somebody search forums. If you think there is better name for thread - contact me or change it by yourself :)
Jasen
Hi guys.

Thanks a lot for all the answers.
It amazed me - how fast and how many people choose to help by posting an answer.

Thanks heaps.
I'm working my way through all the different scenarios.

Cheers
Roy
Brett Nieland
Hi Sergey.
Thanks for your quick reply.
If I understand you correctly, every object definition(customer, supplier), will have it's own db table. (all suppliers will be in suppliers table..).

The way I can add or remove properties at run time is to modify the appropriate table.
This method also allows me to define data-types and other attributes for each property.

Did I understand you correctly

p.s.
The reason that I used "Mark as answer" is because I thought that users get credit for answers on forums, and I wanted to show my appreciation. I apologise if that's the wrong thing do to.
vista adventure
Hi Tim.
The UI should be changed dynamically to reflect the object.

The new properties do not exist in the db. They are created by the user in run-time (apart from very basic properties).
Gargamel
yes.

I think you right. storing the meta data (i.e. what properties each object supports), in an xml's db field is ideal.
It overcomes the problem that relational db has with hierarchical structures.
I think that this is the way to go.

Storing ALL the data in an xml file (not using db at all), will have some major drawbacks:
1. Concurrent users (write) is not supported.
2. Takes long time to load to memory (if using DOM).
3. Does not have optimised search as good as db has.
Choosing deisng pattern

Answer this question