Dynamically generated entity Class Vs. Property Bag

Apr 6, 2010 at 12:53 PM

I'm trying to create a WCF Data Service that leverages IQToolkit's SqlClient to access "resources" in the database.  My problem is I don't have existing CLR objects that represent my entities.  I can think of two routes to take to utilize IQToolkit:

  1. Dynamically generate entity classes based off of my metadata, then translate the incoming query into a query based on these classes...let IQToolkit work its magic.
  2. Rework the SQLProvider to work against untyped objects (well, against a generic "Resource" object that contains a property bag), then translate the incoming query into a query based on this generic "Resource" type.

It would appear option #1 would be the easier of the options to accomplish, but option 2 seems more general.

Any thoughts?


Apr 6, 2010 at 3:40 PM


I'm currently working on a similar solution for an extensible data structure much as yours.  My use case is:
Table: AnimalTable

Table: CatTable

Table: WhaleTable

Depending on the deployment, there's anywhere between 50 and 300 sub animal tables.  It makes no sense to create CLR objects for each deployment as they can drop and add tables at a whim.

My strategy (I'm still sketchy on how it's actually going to work)

Create strongly typed Animal object
Create strongly typed metadata objects (contains table and column information from sys views)
Create a SubAnimal : Animal object which would contain the metadata objects and a dictionary mechanism that would store values for properties
Create a custom entity provider and  entity table which inherits from IQToolkit classes
Override the Insert and Update methods of EntityTable<T>

This is where I'm stuck, trying to get in the middle of the expression tree generation for the various objects. 

Does anybody have a good starting point?

Apr 14, 2010 at 12:52 AM

Check out the IQToolkit Contrib project… it has a code generator and a generic repository.  I think these two items combined would be a good starting point.