3
votes

Est-il possible d'utiliser ensemble Entity Framework et un projet de base de données?

Lors d'une conférence hier, j'ai appris l'importance de mettre votre base de données sous contrôle de code source. Ils nous ont montré comment créer un nouveau projet de base de données et importer la base de données.

Ce que je me demandais, c'est comment je changerais un projet existant s'exécutant sur Entity Framework pour utiliser la puissance du projet de base de données? Les mises à jour de schéma ont toujours été effectuées à l'aide des migrations Entity Framework. Je comprends que le projet de base de données pourra déployer des mises à jour de base de données pour moi et enregistrer ces scripts de mise à jour dans le contrôle de code source, mais je souhaite conserver Entity Framework pour interroger mes données (si cela a du sens).

Est-il possible (ou même: recommandé) d'utiliser Entity Framework pour accéder à la base de données mais gérer la base de données à l'aide d'un projet de base de données dans Visual Studio? Comment procédez-vous?

J'ai essayé de rechercher des questions similaires et d'utiliser Google pour savoir si quelqu'un d'autre a le même problème, mais pas de dés pour l'instant.

Je devrais également indiquer que j'envisage de l'utiliser dans des bases de données qui contiennent également des procédures stockées. Celles-ci ne sont pas du tout contrôlées via Entity Framework et ne sont donc pas encore sous contrôle de code source.

Merci pour votre temps.


3 commentaires

Si vous utilisez des migrations EF pour définir le schéma et que celles-ci sont dans le contrôle de code source, votre base de données est sous contrôle de code source. Avoir également un projet de base de données signifierait qu'il est en double et que quelqu'un pourrait commencer à apporter des modifications directement au projet DB, ce qui, au mieux, va être déroutant. Bien sûr, si vous utilisez des migrations et d'autres choses, la résolution de l'emplacement de mise à jour est beaucoup plus complexe.


C'est vrai, mais les procédures stockées, par exemple, ne sont pas actuellement sous contrôle de code source. C'est pourquoi j'envisage le projet de base de données.


Si vous utilisez SSDT, vous disposez d'un mécanisme beaucoup plus puissant pour publier et apporter des modifications aux bases de données cibles. Les migrations EF sont uniquement destinées au développement et aux modifications (très) simples. Ils ne peuvent pas gérer les migrations de données , ils ne peuvent pas détecter les changements de schéma ou générer des scripts basés sur ces changements. En fait, vous pouvez publier votre projet de base de données en tant que dacpac , puis le comparer avec une base de données cible à partir de la ligne de commande pour générer le script de modification


3 Réponses :


0
votes

J'ai développé une application comme celle-là, ayant 2 projets: l'application elle-même et le projet SSDT pour la base de données. Les modifications de la base de données ont été déployées via des scripts de modification et les migrations EF ont été désactivées dans l'application.

Tout fonctionnait bien, même si cela apportait un peu de frais généraux. Par exemple, il était un peu compliqué d'introduire des mises à jour / refactorisations majeures de la base de données dans la couche EF. Pour une raison quelconque, je n'ai pas pu procéder à l'ingénierie inverse des modifications de la base de données directement dans l'application, j'ai donc dû le faire à moitié manuellement: créer un nouveau projet, générer un contexte EF pour toute la base de données, puis copier les fichiers nouveaux / modifiés dans l'application principale .

(Encore une fois, c'était il y a presque 5 ans. Avec de la chance, les échafaudages EF se sont améliorés depuis.)


0 commentaires

2
votes

Ce que je me demandais, c'est comment je changerais un projet existant s'exécutant sur Entity Framework pour utiliser la puissance du projet de base de données?

Réponse: Je vous suggère de voir ce cours de Plural Sight: https://www.pluralsight.com/courses/code-first-entity-framework-legacy-databases

Est-il possible (ou même: recommandé) d'utiliser Entity Framework pour accéder à la base de données mais gérer la base de données à l'aide d'un projet de base de données dans Visual Studio? Comment procédez-vous?

Réponse: Oui, c'est possible et recommandé. Votre projet de données devient la source de vérité sur la structure de votre base de données. Ceci est très puissant pour garder le contrôle de toutes les modifications et de l'état de votre base de données en un seul endroit (Visual Studio). Le cours de la première réponse vous apprendra comment.

Je devrais également indiquer que j'envisage de l'utiliser dans des bases de données qui contiennent également des procédures stockées. Celles-ci ne sont pas du tout contrôlées via Entity Framework et ne sont donc pas encore sous contrôle de code source.

Réponse: Je ne vois aucun problème lors de l'utilisation des procédures stockées. L'outil du cours Plural Sight créera la procédure dans votre contrôle de code source et le reverse engineering créera une classe / méthode pour une utilisation facile de la procédure.


0 commentaires

0
votes

Je viens de tomber sur l'alternative ci-dessous, que je n'ai pas testée cependant:

Générer des classes Entity Framework Core à partir d'un projet de base de données SQL Server - fichier .dacpac

Je pense que cela devrait être quelque chose à considérer


0 commentaires