3

Je suis impatient de déplacer toute la logique (qui est implémentée en manipulant les objets Entity Framework 4) vers un serveur. Il semble être simple (grâce à la structure de l'application) et bénéfique (tout ce que j'ai est un vieux portable comme un client et un serveur dur qui exécute SQL Server 2008, et la construction d'un service séparé pour la logique peut simplement introduire plus de latence si on le compare à le faire dans la base de données).Comment utiliser Entity Framework dans une procédure stockée CLR?

Alors, comment utiliser correctement Entities Framework dans une procédure stockée CLR et le faire en utilisant un SqlContext fourni par le serveur hôte?

Soudain, je n'ai trouvé aucun exemple sur le Web. On dirait que personne n'en a encore mangé. Cela signifie-t-il que la tâche est ridicule et que je ne devrais certainement pas faire cela? Il ne sera pas très pratique d'utiliser T-SQL et d'accéder directement aux tables à la place des classes EF car mon modèle utilise beaucoup l'héritage et possède une structure table-par-type très complexe de beaucoup de tables très simples.

+3

« aucun n'a encore fait "... devrait sonner quelques cloches. Ce n'est pas la façon dont les procédures stockées CLR sont supposées être utilisées. –

Répondre

1

Non, vous ne pouvez pas. Visual Studio ne vous permet même pas d'ajouter le type de fichier ou de projet. (C'est dommage, je voulais le faire aussi pour traiter une logique vraiment complexe.)

2

Vous ne pouvez pas - du moins pas pour le moment. Le CLR contenu dans SQL Server 2005 à 2008 R2 est .NET 2.0 CLR - et Entity Framework 4 requiert le framework .NET 4. Pour l'instant, lorsque vous faites des choses dans une méthode SQL-CLR, vous êtes limité à ADO.NET 2.0 uniquement.

La plus grande question demeure: pourquoi voudriez-vous utiliser EF4 dans une fonction SQL-CLR? Ceux-ci sont destinés à être stockés proc, les fonctions définies par l'utilisateur, les agrégats définis par l'utilisateur - mais certainement pas les applications de base de données à part entière, vraiment ...

2

Certains d'entre nous ne sont pas si désireux de maintenir des métadonnées de schéma de base de données à deux endroits ou plus. EF est génial pour ce faire, mais si l'on veut utiliser les avantages de performance de SQL-CLR, le schéma doit être défini dans son contexte. Ce qui signifie pour le moment un code de métadonnées personnalisé dans l'assemblage SQL-CLR qui génère DDL pour définir une base de données et l'importer dans EF.

1

Semble qu'avec SQL Server 2008 R2 ou plus vous pouvez, il utilise .NET ver. 4.0. Voir this blog.

je lance la commande suivante contre mon SQL Server 2010 Developer Eeition:

select value from sys.dm_clr_properties where name = 'version' 

et a obtenu le résultat suivant:

v4.0.30319

+0

Ce n'est pas entièrement vrai. Tout d'abord, la version CLR de SQL Server 2008 R2 est toujours 2.0, mais elle peut utiliser Framework Version 3.5. Et, juste parce que la version CLR de SQL Server 2012, 2014 et 2016 est 4.0, cela ne signifie pas que vous pouvez importer n'importe quelle DLL Framework que vous voulez. Il doit toujours être une bibliothèque/DLL pure-MSIL. S'il est mélangé, il ne sera pas importé, même s'il s'agit de la version CLR correcte. –