Plans for dynamic cached lookup of DLinq Table classes?
The video example includes a code generation tool that "may" become part of a future Visual Studio to generate classes to represent SQL Tables for DLinq.Someone has already posted a Code Smith template to do something similar.
I'm interested in a run time capability that can reference tables by name and generate matching DLinq Table classes at runtime. I work with systems that have tables whose information is often extended (so theMeta data is not very stable) but my queries are static (the Tables/Columns names don't change). The ability to generate the table class for DLinq could use the Light Weight Runtime Compilation capability that was added in .NET 2.0 and could be cached (and kept up to date at run time with the new SQL Server 2005 schema change notification capabilities.) We would need to add some wrapper exception handling to verify that none of the queries access columns that mismatch the generated class and to handle schema change notifications from the SQL Server.
The startup overhead of runtime generation (if cached) would be more than offset by the lowered overhead costs. The ability for the system to regenerate the Table classes while the program is running to track a changing schema would be invaluable in keeping uptime on our clients with minor changes on a running production system.
It does not sound like you are planning to use the extensions to the schema, your queries are using static columns. You should be able to use a view on the table to use DLinq for those queries with no need for dynamic schema. If the issue is propagation of user data during your updates, that should be a much more solvable than dynamic schema classes.
Views are useful in some contexts and in cases where views and/or stored procedures are allowed we use them. However separate maintenance of the middle tier and the database views & stored procedures is something I'm trying to avoid for some of the applications. Also some of the databases the developers only have DLM (Data Manipulation Language e.g. SELECT, ADD, DELETE, UPDATE) access. They do not own the schema nor do we have administrative rights to add to or change the schema.
Basically we would like to decouple the application schema and the database schema as much as possible. Put hooks in to disable application functionality (until it can be patched) if the change in schema breaks the interface. Not everyone owns the database they are trying to access, especially when crossing departmental boundaries in a large company.
There are many workarounds to these problems so I’m not stuck but they all have costs. One can use dynamic ad-hoc queries but with a performance cost. One can forgo using a strongly typed data access layer but with a maintenance overhead and reliability cost. One can build their own dynamic run time compiled query system but only with another mountain of code to maintain.
I've been hoping that with the paradigm shift that LINQ represents that the basic model will be supportive of strongly typed compiled runtime queries. This would be very similar to what happened with the XML parser in the 2.0 release. They went from an interpreted engine to a true MSIL complier as an option on the backend (with large performance gains as the payoff.) I would hope that in 3.0 LINQ will at least set the stages for doing this in a future release for language embedded middle tier queries.
