Design for extensibility of objects and properties
Can anybody guide me in designing application that can be easily extendable and customizable?
How does Microsoft design the products like Dynamics NAV or CRM which allows others to build properties and objects and integrate with the existing objects given by Microsoft? I guess, Microsoft does not provide source code for the products; still they are extendable.
Also, the UI is highly configurable.
Any help on this on how to start something like that will be appreciated.
Thanks in advance.
Satyajit Behera, May 23, 2010
A while ago I was involved with a project where we asked the same questions.
I am not familiar with Dynamics NAV or CRM but at SalesForce.com they have the same functionality. They allow users to create their own custom objects and fields (properties), then save these, and from then on these items behave as they have been there from the beginning. These new items integrate flawlessly within the application.
When designing a system that has this kind of runtime configurabilty, I would suggest you start with the data model (schema). The data model is the most critical because when you don't do it right your performance will go down the tubes (very quickly).
There are different database approaches:
One way is an absolute generic data model, which has a Thing table (object) and a NameValue table (property and their values). In this model all properties are stored as character strings.
Alternatively, you can can also use special tables that store typed data for custom columns (one table for string data, one table for int data, one for datetime, etc). This works for custom properties, but not so well for custom objects.
Another alternative is to store custom objects and their properties in blobs or possibly in the new XML column type (in SQL Server 2005 and up). The problem is getting data out of this format. It is either impossible (blob) or difficult (XML). Personally, I have experience wth the blob model and I would recommend against using it.
In all cases you must carefully consider performance and the relations with existing tables (such as joins, etc).
As far as objects are concerned you need flexibilty. I suggest you use ADO.NET's DataTables and DataRows for this purpose. They are also fairly performant.
Anyhow, I just wanted to throw some ideas out there. But it is not an easy problem to solve.
Bogusław Dobrogost, May 28, 2010