EF & .EDMX performance considerations

I'm doing a spot of research surrounding Entity Framework and its associated .edmx files.

Our current setup has a number of these files compiled in to a library that we use extensively. Of course, this isn't exaclty an elegant solution - e开发者_如何学运维very time we want to update or add to something in the database layer, we need to recompile this library.

We use stored procedures exclusively, and our current approach is to use the ExecuteFunction method on the object context. However, this does require knowledge of what imported functions from an edmx file return what type (context.ExecutionFunction<T>() returns ObjectResult<T>).

My theoretical solution is to store any .edmx files we want to use at a relative path, and have the library load them all at run time.

Has anybody tried this before? Does it work? Are there any performance considerations to take in to account? This would be used in an ecommerce environment, so efficiency and speed is important.

EDIT FOR SOME MORE CLARITY:

It would certainly be possible to compile each individual .edmx file in to its own assembly, which might allow the use of this. Any input on that, too, would be great.

The call we make now is something like this

Database.MakeCall<T>("stored_procedure_name", parametersCollection, KnownDatabases.Database);

In its constructor, the database handler will hold instances of each of the database contexts it knows about (each of the.edmx files in the library) . Using the KnownDatabases enum, it chooses which database to run the query against.

Ideally, I'd like to achieve a call like this:

Database.MakeCall<T>("context_name", "stored_procedure_name", parametersCollection);

Where in the database handler will, in its constructor, search a folder for .edmx files and load them all, then store instances of each context against the context name. How T would be defined or obtained is a little blurry right now.

In both cases, the return type would be ObjectResult<T>

What you might like to consider is a ruby-esque DB mapping, one where the DB schema is determined at runtime so you do not need to maintain the DB-ORM mapping library code.

For .net, Subsonic has such an ORM as does Castle and nHydrate. I know such a system can perform well as a C++ implementation (ODB) had some good performance stats (even if it does generate code romt he schema, but it does this automatically)