.net Extendable data layer...ideas please

Question

This may be an impossible question - but if anyone has any ideas, even if it's a bespokely written solution

We're trying to come up with an idea for a simple program to send out to people, backed by a database. At a simplistic level, there will be a "User" object, which just has name and email. The program just allows someone to edit the name and email, and all is good

Then we want other developers to be able to add their own fields, and write a "plug-in" to edit it. So, I've got a copy of the program, I've been able to write my plugin that adds "comany name" to the form - and it could stand alone with the data layer, but the problem with this method is that you end up running two database commands

select name, email from user select companyname from user

Ideally, it would be really cool if the plugin to add something to the datalayer to say, include companyname on user, then you only have one command

select name, email, companyname from user

Perfect...but how

Ideas on a postcard - or at least as an answer on here

Answer 1

I am not sure what you mean when you say "plug-in": If the plug-in user class inherits from the base user class you could create a virtual method void GetFieldValues(Dictionary that is called when the sql is being built. The plug-in would add its fields, call the base version who would then add his own fields. The use of 'Object' in the dictionary will cause Boxing / Unboxing with value types, so you could wrap the value type in a class to prevent this. If inheritance is not an option you could define an interface with the method in it that both classes would have to implement and call the method on both classes at the appropriate time.

Answer 2

What about adding an XML field as additional data to your users table, so the "plugin" programmer can add any data into it.

MS SQLServer (from 2005 version I think) allows you to query into the xml from the main query, so you could also provide an entry point for adding some conditions to the where clause if needed.

So, if you always get the information into the XML field, then the plugin developer will only have to read and write the values he wants into the xml, and fill the controls he has created.

Answer 3

I think I've found as close as I'm going to get - Fluent NHibernate seems to offer a lot of potential in this area