Si votre objectif principal est de créer d'abord les tables dans la base de données, puis de mettre à jour automatiquement votre projet, vous devez utiliser Database First.
Cela dit, vous devez tenir compte des inconvénients de Database First :d'après mon expérience personnelle, j'ai arrêté d'utiliser cette approche principalement pour deux raisons :
- Pour autant que je sache, l'assistance Database First sera interrompue. EF Core n'inclut pas l'outil d'édition. Quelques liens à ce sujet :un message de Julie Lerman , la feuille de route EF Core , et une première annonce de Microsoft .
- L'éditeur de modèles présentait plusieurs bogues et bizarreries qui provoquaient des pannes de code de temps en temps. Ces bogues ne seront probablement pas corrigés (voir le point précédent). Des choses comme changer le type d'un champ existant, changer les clés étrangères, etc.
- J'ai eu beaucoup de problèmes à cause de la fusion des référentiels de code source des fichiers d'entité générés automatiquement. Surtout (mais pas seulement) lorsque plusieurs personnes travaillaient avec les mêmes entités, nous obtenions donc des conflits de fusion dans le code généré automatiquement. De plus, le code généré automatiquement n'était parfois pas extrait correctement, il était donc désynchronisé avec edmx. Je ne suis pas sûr que cela arrive aussi à d'autres personnes, mais il semble que parfois Visual Studio, l'éditeur, l'outil de génération de code automatique en arrière-plan et le gestionnaire de code source TFS ne fonctionnent tout simplement pas bien ensemble.
Donc, si vous ne pouvez vraiment pas vivre sans créer d'abord les tables de la base de données, continuez avec Database First, mais vous devez considérer ce que vous perdez si vous n'utilisez pas Code First. Cette approche est largement recommandée pour une raison.
Habituellement, la principale raison pour laquelle les personnes utilisent Database First de nos jours est l'impossibilité de migrer le code hérité vers l'approche Code First. Autant que je sache, il est largement admis que Code First est la bonne façon de procéder autrement. Ici vous avez un article intéressant à ce sujet (même s'il est un peu ancien, écrit pour EF 4.1, lorsque Code First a été introduit, il traite des principaux avantages et inconvénients de chaque approche).
Une solution de contournement pour vous pourrait être de continuer à utiliser Code First, mais également d'utiliser les outils disponibles qui génèrent automatiquement vos entités Code First en effectuant une ingénierie inverse à partir des tables de la base de données. Avec cela, vous pouvez toujours générer vos tables directement dans la base de données, mais continuez à utiliser Code First avec les migrations et tout. Ici vous avez un article de Julie Lerman sur certains de ces outils . Il existe peut-être des outils plus récents, mais je ne les ai pas utilisés et je ne les connais pas.
Remarque :mon expérience personnelle avec Database First a été plutôt mauvaise et n'a pas duré trop longtemps. Peut-être que quelqu'un ayant une expérience plus positive de cette approche pourrait donner un aperçu plus utile à ce sujet. J'utilise Code First depuis un certain temps maintenant et je préfère vraiment cette approche. Ma réponse est peut-être un peu biaisée.
