Sql Server Data Tools & Entity Framework - y a-t-il une synergie ici?

Sortant d'un projet utilisant Linq2Sql, je soupçonne que le prochain (plus gros) pourrait me pousser dans les bras d'Entity Framework. J'ai fait quelques lectures sur le sujet, mais ce que je n'ai pas réussi à trouver est une histoire cohérente sur la façon dont les outils de données SQL Server et Entity Framework devraient / pourraient / pourraient être utilisés ensemble.

• Ont-ils été conçus de manière totalement distincte et les utiliser ensemble est-il un mauvais choix?
• Sont-ils en quelque sorte totalement orthogonaux et je manque le point?

Quelques raisons pour lesquelles je pense que je pourrais vouloir les deux:

• SSDT est idéal pour avoir un SQL et un schéma «compilés» (vérifiés) et facilement modifiables
• Mais l'histoire de la «migration / mise à jour» du SSDT n'est pas convaincante (pour moi): «Mettre à jour quoi que ce soit» fonctionne bien pour le schéma, mais il n'y a aucun moyen (AFAIK) qu'il puisse jamais fonctionner pour les données.
• D'un autre côté, je n'ai pas essayé la migration EF pour savoir si elle présente des problèmes similaires, mais les bits Up / Down semblent assez pratiques.

Permettez-moi de présenter un autre point de vue. La maintenance de la base de données Entity Framework est totalement inutile dans toute entreprise ou tout grand projet de base de données.

Les problèmes sont:

• Mises à jour automatiques du schéma. Ce n'est absolument pas ce que je veux car cela viole totalement les principes fondamentaux de la maintenance de la base de données. Les problèmes sont: (a) quelqu'un exécutant une version plus récente met à jour la base de données au lieu d'obtenir un problème et (b) les mises à jour sont planifiées avec le dba prenant normalement une sauvegarde en PREMIER. Les mises à jour automatiques sont donc inutiles.

• La création de base de données ne fonctionne que sur les cas de bord essentiellement dégénérés. N'essayez même pas d'utiliser des fonctionnalités avancées de base de données, quelle que soit celle-là. Exemple de serveur SQL: champs inclus dans les index, filtres sur les index, partitionnement, compression, règles de validation des champs.

• Migration - suppose à nouveau des cas marginaux dégénérés: aucune transformation de données ou mise à jour en plusieurs étapes facilement. Exemple: le tableau X a un champ "utilisateur" historique qui enregistre l'utilisateur fait quelque chose. La nouvelle configuration a une table utilisateur, il faut donc créer la table utilisateur, puis créer les utilisateurs, puis créer le champ de référence utilisateur dans la table x, puis la mettre à jour avec l'utilisateur, c'est de la table utilisateur, puis supprimer le champ utilisateur.

La seule façon judicieuse de gérer ces scénarios est la génération et la migration de scripts et le bon contrôle de version.

Maintenant, SSDT - qui est un excellent outil pour versionner une version de base de données spécifique bien mieux qu'Entity Framework car il fonctionne - fonctionne. Comme dans: il enregistre toutes les fonctionnalités. Sur aucune des bases de données que je possède, je pouvais à peu près utiliser le code en premier - parce que nous avons toujours au moins des indices filtrés;) EF ne me permettrait même pas d'atteindre 10% de ce dont j'ai besoin.

Notre approche est:

• Concevez la base de données dans la base de données, puis synchronisez-la avec un module SSDT qui est archivé. La synchronisation de schéma permet aux développeurs de mettre à jour leur version rapidement. Il y a toujours une base de données maître faisant autorité avec la version actuelle quelque part (sur un serveur spécial), nous avons donc une version de référence sur laquelle travailler.

• Générez des scripts delta selon les besoins pour les versions qui sont également versionnées et disposent d'un mécanisme agréable pour les déployer dans une base de données.

Il existe plusieurs façons d'utiliser EF avec une base de données SQL Server.

1. Code-First ... Vous écrivez des classes et EF génère les tables associées
2. Base de données d'abord ... Vous concevez les tables et EF génère les classes.

EF ne fera pas nécessairement tout le travail pour vous. EF vous y amènera entre 80 et 95%. Les 5 à 20 pour cent restants de votre effort de développement de base de données seront complétés par des optimisations telles que les vues et les procédures stockées.

Donc non, ils ne sont pas orthogonaux. Mais vous devrez décider quelle sera votre stratégie de conception globale, puis compter sur des outils comme SSDT pour vous aider à optimiser les pièces où EF produit des résultats moins qu'idéaux.