Question

My project requires me to create a database object (a custom class) containing a list of tables, each table containing a list of columns. The columns and tables object have specific properties not available in the database. For example label, max value, min value and so on.

All these custom properties are stored in database tables, which the user can modify. These properties will be used in various web forms.

My question: Is is wise to keep connecting to the database to find out these extended properties for each form, OR create a object (as explained above) and store all the tables, columns as lists and store that BIG object as an application variable.

I was also thinking to put the object in the cache and expire it whenever users make changes to the extended properties.

Can someone tell me if the best of the above 3 approaches or any other method to ensure best performance.

Thanks

Edit: This has to be a generic solution that should work on ANY database. So potentially, there could be a large number of tables (50-120) each having 10-30 columns

Edit2: I was also thinking of dynamically creating classes (like Entity framework does) and loading them using reflections.

Answer 1

Seeing as you are only caching meta data and no data, the amount to store is relatively small.

You have two options, as I see it:

• Store in the Application object, which is available to all sessions and will not expire (but will be around until the app pool is reset)
• Store in a Cache entry which allow you to set a future expiration or database dependency so you can refresh the data.

Since you say the user can change the data, a Cache with a database dependency looks like the right choice, though this is only supported directly with the SqlCacheDependency class (so only applies to SQL Server).

A more generic approach would be a cache that expires and causes a polling of the DB on expiration.