views:

121

answers:

2

Looking for advice, links, design patterns, etc. on the best way to design an application where entities and related screens could be extended with additional attributes/related lookups via metadata/without recompile, ideally by end users. I'm thinking something very similiar to how Dynamics CRM 4.0 works with extension tables/dynamic properties. This application would be built using C# .NET 3.5

Thanks!

+1  A: 

You can do this sort of thing by writing your own PropertyDescriptor implementation, and either implementing ICustomTypeDescriptor (adds properties to an instance), or by using a TypeDescriptionProvider (can add properties to an entire type).

This is a common way of implementing extensible/dynamic property-bag implementations, and is what things like DataTable use under the hood to expose virtual properties (on DataRowView etc).

However; it is a lot of work. I've done it a few times, and it isn't fun. I wonder whether you should just use a per-canned solution? While I normally avoid DataTable, this might be one of the occasions where it is genuinely useful... just add columns, and job done.

Marc Gravell
A: 

I have worked on two projects, one a Telco Content Management System portal, another an Identity Management System.

Both are customization of products, and both support what you described as extensions of entities. And both store the data as.. an XML strings! (1 of them in database, the other in SVN).

For searching, one of them utilize Lucene, and the other has a table of name/value pair for searching, with optimization for some more frequently used 'fields' defined by the user to be store in the same row as the XML string..

The entity schema are both driven by XML config files.

As a product, I would almost think they are good idea, allowing customization of entities to suit different scenarios. But when I was customizing them, it was just plain.. irritating.

I think it's probably best to approach this from an end user customer point of view.

  1. Given the ability to extend the entity as they wish, who would be the person extending them? A programmer? A business user?
  2. Given that you have narrow them down to who will be doing the 'customization', how can you make it a more pleasant experience? Drive the design from usage.

In addition, consider this: Do you really need an RDBMS for this, or a document-oriented storage like CouchDB will do? IMO a Document-oriented storage seems ideal for extensible entities. But I have not work with them and does not have the necessary data on if they are useful.

Just my 2 cents worth. Hope it helps.

Kent Lai