Considérations relatives aux performances EF et .EDMX

Question

Je suis en train de faire des recherches sur Entity Framework et ses fichiers .edmx associés.

Notre configuration actuelle contient un certain nombre de ces fichiers compilés dans une bibliothèque que nous utilisons intensivement. Bien sûr, ce n'est pas vraiment une solution élégante - chaque fois que nous voulons mettre à jour ou ajouter quelque chose dans la couche de base de données, nous devons recompiler cette bibliothèque.

Nous utilisons exclusivement des procédures stockées, et notre approche actuelle consiste à utiliser la méthode ExecuteFunction sur le contexte de l'objet. Cependant, cela nécessite de connaître les fonctions importées à partir d'un fichier edmx pour renvoyer quel type (context.ExecutionFunction<T>() renvoie ObjectResult<T>).

Ma solution théorique est de stocker tous les fichiers .edmx que nous voulons utiliser à un chemin relatif, et de les charger tous au moment de l'exécution.

Quelqu'un a déjà essayé cela? Est-ce que ça marche? Y a-t-il des considérations de performance à prendre en compte? Cela serait utilisé dans un environnement de commerce électronique, donc l'efficacité et la rapidité sont importantes.

EDIT POUR CERTAINS PLUS CLARITY:

Il serait certainement possible de compiler chaque fichier .edmx individuel pour sa propre assemblée, ce qui pourrait permettre l'utilisation de this. Toute contribution à ce sujet serait également formidable.

L'appel que nous faisons est maintenant quelque chose comme ça

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

Dans son constructeur, le gestionnaire de base de données contenir des instances de chacune des bases de données des contextes qu'il connaît (chacun des the.edmx fichiers dans la bibliothèque) . À l'aide de l'énumération KnownDatabases, il choisit la base de données sur laquelle exécuter la requête.

Idéalement, je voudrais réaliser un appel comme celui-ci:

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

Où dans le gestionnaire de base de données, dans son constructeur, rechercher un dossier pour les fichiers .edmx et charger tous, puis instances de magasin de chaque contexte par rapport au nom du contexte. Comment T serait défini ou obtenu est un peu flou en ce moment.

Dans les deux cas, le type de retour serait ObjectResult<T>

Answer 1

Ce que vous pourriez envisager est une application DB rubis-esque, celui où le schéma de DB est déterminé lors de l'exécution de sorte que vous n'avez pas besoin de maintenir la DB -ORM code de la bibliothèque de mappage. Pour .net, Subsonic a un ORM tel que Castle et nHydrate. Je sais qu'un tel système peut bien fonctionner car une implémentation C++ (ODB) a de bonnes stats de performance (même si elle génère du code mais il le fait automatiquement)