Question Code-first vs Model / Database-first


Quels sont les avantages et les inconvénients de l'utilisation d'Entity Framework 4.1 Code-first sur Model / Database-first avec le diagramme EDMX?

J'essaie de comprendre complètement toutes les approches de construction de la couche d'accès aux données en utilisant EF 4.1. J'utilise le modèle Repository et IoC.

Je sais que je peux utiliser l'approche code-first: définir mes entités et le contexte à la main et utiliser ModelBuilder pour affiner le schéma.

Je peux aussi créer un EDMX diagramme et choisissez une étape de génération de code qui utilise des modèles T4 pour générer le même POCO Des classes.

Dans les deux cas, je me retrouve avec POCO objet qui sont ORM agnostique et le contexte qui dérive de DbContext.

La base de données semble d'abord être la plus attrayante puisque je peux concevoir une base de données dans Enterprise Manager, synchroniser rapidement le modèle et l'affiner en utilisant le concepteur.

Alors, quelle est la différence entre ces deux approches? Est-ce juste à propos de la préférence VS2010 vs Enterprise Manager?


570
2018-03-27 00:17


origine


Réponses:


Je pense que les différences sont:

Code d'abord

  • Très populaire parce que les programmeurs inconditionnels n'aiment aucun type de concepteur et que la définition du mappage dans EDMX xml est trop complexe.
  • Contrôle total sur le code (pas de code généré automatiquement qui est difficile à modifier).
  • L'attente générale est que vous ne vous embêtez pas avec DB. DB est juste un stockage sans logique. EF gère la création et vous ne voulez pas savoir comment cela fonctionne.
  • Les modifications manuelles de la base de données seront probablement perdues car votre code définit la base de données.

Base de données première

  • Très populaire si vous avez DB conçu par DBA, développé séparément ou si vous avez déjà DB.
  • Vous laisserez EF créer des entités pour vous et après la modification de la cartographie, vous générerez des entités POCO.
  • Si vous souhaitez ajouter des entités supplémentaires dans les entités POCO, vous devez soit modifier le modèle T4, soit utiliser des classes partielles.
  • Des modifications manuelles dans la base de données sont possibles car la base de données définit votre modèle de domaine. Vous pouvez toujours mettre à jour le modèle depuis la base de données (cette fonctionnalité fonctionne assez bien).
  • J'utilise souvent ceci ensemble des projets de base de données VS (seulement la version Premium et Ultimate).

Modèle premier

  • IMHO populaire si vous êtes fan de concepteur (= vous n'aimez pas l'écriture de code ou SQL).
  • Vous allez "dessiner" votre modèle et laisser le workflow générer votre script de base de données et le template T4 générer vos entités POCO. Vous perdrez une partie du contrôle de vos entités et de votre base de données, mais pour de petits projets faciles, vous serez très productif.
  • Si vous souhaitez ajouter des entités supplémentaires dans les entités POCO, vous devez soit modifier le modèle T4, soit utiliser des classes partielles.
  • Les modifications manuelles de la base de données seront probablement perdues car votre modèle définit la base de données. Cela fonctionne mieux si vous avez installé le module d'alimentation de la base de données. Il vous permettra de mettre à jour le schéma de la base de données (au lieu de le recréer) ou de mettre à jour les projets de la base de données dans VS.

Je m'attends à ce que dans le cas d'EF 4.1, il y ait plusieurs autres caractéristiques liées au Code d'abord par rapport au Modèle / Base de données en premier. L'API Fluent utilisée dans Code d'abord n'offre pas toutes les fonctionnalités d'EDMX. Je m'attends à ce que des fonctionnalités telles que le mappage de procédures stockées, les vues de requête, la définition de vues, etc. DbContext(Je ne l'ai pas encore essayé) mais ils ne le font pas dans le code d'abord.


642
2018-03-27 01:27



Je pense que ce simple "arbre de décision" de Julie Lerman, l'auteur de "Programming Entity Framework", devrait aider à prendre la décision avec plus de confiance:

a decision tree to help choosing different approaches with EF

Plus d'informations Ici.


121
2017-10-09 17:45



Base de données d'abord et le modèle d'abord n'a pas de réelles différences. Le code généré est le même et vous pouvez combiner ces approches. Par exemple, vous pouvez créer une base de données en utilisant designer, que vous pouvez modifier la base de données en utilisant le script SQL et mettre à jour votre modèle.

Lorsque vous utilisez le code en premier, vous ne pouvez pas modifier le modèle sans base de données de loisirs et perdre toutes les données. À mon humble avis, cette limitation est très stricte et ne permet pas d'utiliser le code d'abord en production. Pour l'instant ce n'est pas vraiment utilisable.

Le deuxième inconvénient mineur du code est que le constructeur de modèle requiert des privilèges sur la base de données master. Cela ne vous affecte pas si vous utilisez la base de données SQL Server Compact ou si vous contrôlez le serveur de base de données.

L'avantage du code est d'abord le code très propre et simple. Vous avez le plein contrôle de ce code et pouvez facilement le modifier et l'utiliser comme modèle de vue.

Je peux recommander d'utiliser la première approche du code lorsque vous créez une application autonome simple sans versioning et en utilisant model \ database d'abord dans les projets qui nécessitent une modification en production.


44
2018-01-31 07:38



Citant les parties pertinentes de http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework

3 raisons d'utiliser le premier design de code avec Entity Framework

1) Moins de cruft, moins de ballonnement

Utiliser une base de données existante pour générer un fichier de modèle .edmx et le   Les modèles de code associés résultent en une pile géante de code généré automatiquement.   Vous êtes imploré de ne jamais toucher ces fichiers générés de peur de vous casser   quelque chose, ou vos changements sont écrasés sur la prochaine génération. le   le contexte et l'initialiseur sont également coincés dans ce désordre. Quand   vous devez ajouter des fonctionnalités à vos modèles générés, comme un   propriété en lecture seule calculée, vous devez étendre la classe de modèle.   Cela finit par être une exigence pour presque tous les modèles et vous finissez   avec une extension pour tout.

Avec le code d'abord vos modèles codés à la main deviennent votre base de données. L'exact   Les fichiers que vous construisez sont ce qui génère la conception de la base de données.   Il n'y a pas de fichiers supplémentaires et il n'est pas nécessaire de créer une classe   extension lorsque vous voulez ajouter des propriétés ou tout ce que le   base de données n'a pas besoin de savoir. Vous pouvez simplement les ajouter dans le   même classe tant que vous suivez la syntaxe appropriée. Heck, vous pouvez même   générer un fichier Model.edmx pour visualiser votre code si vous le souhaitez.

2) Un plus grand contrôle

Quand vous allez DB d'abord, vous êtes à la merci de ce qui est généré pour   vos modèles pour une utilisation dans votre application. Parfois, la dénomination   la convention est indésirable. Parfois, les relations et   les associations ne sont pas tout à fait ce que vous voulez. Autres fois non transitoires   les relations avec le chargement paresseux causent des ravages sur vos réponses API.

Alors qu'il y a presque toujours une solution pour les problèmes de génération de modèles   vous pourriez tomber sur, en commençant par le code qui vous donne complète et bien   contrôle granulaire dès le départ. Vous pouvez contrôler tous les aspects des deux   vos modèles de code et votre conception de base de données dans le confort de votre   objet métier. Vous pouvez spécifier précisément les relations, les contraintes,   et associations. Vous pouvez définir simultanément des limites de caractères de propriété   et tailles des colonnes de la base de données. Vous pouvez spécifier les collections associées   doivent être chargés, ou ne pas être numérotés du tout. En bref, vous êtes   responsable de plus de choses, mais vous êtes en plein contrôle de votre application   conception.

3) Contrôle de version de base de données

C'est un gros. Les bases de données de versioning sont difficiles, mais avec le code d'abord   et coder les premières migrations, c'est beaucoup plus efficace. Parce que votre   le schéma de base de données est entièrement basé sur vos modèles de code, par version   contrôler votre code source vous aide à la version de votre base de données.   Vous êtes responsable de contrôler l'initialisation de votre contexte qui   peut vous aider à faire des choses comme des données d'affaires fixes de semences. Vous êtes aussi   responsable de la création de premières migrations de code.

Lorsque vous activez d'abord les migrations, une classe de configuration et une   la migration est générée. La migration initiale est votre schéma actuel   ou votre version de base v1.0. À partir de ce moment, vous ajouterez des migrations   qui sont horodatés et étiquetés avec un descripteur pour aider à   commande de versions. Lorsque vous appelez l'ajout de migration à partir du package   gestionnaire, un nouveau fichier de migration sera généré contenant tout   cela a changé dans votre modèle de code automatiquement dans un UP () et   DOWN () fonction. La fonction UP applique les modifications à la base de données,   la fonction DOWN supprime ces mêmes changements dans le cas où vous voulez   rollback. De plus, vous pouvez modifier ces fichiers de migration pour ajouter   modifications supplémentaires telles que les nouvelles vues, les index, les procédures stockées et   n'importe quoi d'autre. Ils deviendront un vrai système de versioning pour votre   schéma de base de données.


27
2018-05-09 20:06



Code-premier semble être l'étoile montante. J'ai jeté un coup d'œil à Ruby on Rails, et leur standard est le code d'abord, avec les migrations de base de données.

Si vous construisez une application MVC3, je crois que Code a d'abord les avantages suivants:

  • Décoration d'attribut facile - Vous pouvez décorer des champs avec validation, require, etc .. attributs, c'est assez gênant avec la modélisation EF
  • Pas d'erreurs de modélisation bizarres - La modélisation EF a souvent des erreurs étranges, comme lorsque vous essayez de renommer une propriété d'association, elle doit correspondre aux méta-données sous-jacentes - très inflexible.
  • Pas gênant de fusionner - Lors de l'utilisation d'outils de contrôle de version de code tels que mercurial, la fusion de fichiers .edmx est pénible. Vous êtes un programmeur habitué à C #, et là vous fusionnez un .edmx. Pas si avec le code d'abord.
  • Comparez d'abord le code et vous avez le contrôle complet sans toutes les complexités cachées et les inconnues à traiter.
  • Je vous recommande d'utiliser l'outil de ligne de commande du Gestionnaire de package, n'utilisez même pas les outils graphiques pour ajouter un nouveau contrôleur aux vues d'échafaudage.
  • DB-Migrations - Ensuite, vous pouvez également activer les migrations. C'est tellement puissant. Vous apportez des modifications à votre modèle dans le code, puis le framework peut suivre les modifications du schéma, ce qui vous permet de déployer des mises à niveau de manière transparente, avec des versions de schéma mises à jour automatiquement (et rétrogradées si nécessaire). (Je ne suis pas sûr, mais cela fonctionne probablement aussi avec modèle-premier)

Mettre à jour

La question demande également une comparaison du code-first au modèle EDMX / db-first. Le code-first peut également être utilisé pour ces deux approches:


25
2017-07-26 02:37



J'utilise d'abord la base de données EF afin de fournir plus de flexibilité et de contrôle sur la configuration de la base de données.

Le code EF d'abord et le modèle ont d'abord semblé cool, et offrent une indépendance de base de données, cependant, ce faisant, il ne vous permet pas de spécifier ce que je considère comme des informations de base de données de base. Par exemple, les index de table, les métadonnées de sécurité ou une clé primaire contenant plus d'une colonne. Je trouve que je veux utiliser ces fonctions et d'autres fonctionnalités de base de données communes et, par conséquent, avoir à faire de la configuration de base de données directement de toute façon.

Je trouve que les classes POCO par défaut générées au cours de la première DB sont très propres, mais manquent des attributs d'annotation de données très utiles, ou des mappages aux procédures stockées. J'ai utilisé les modèles T4 pour surmonter certaines de ces limitations. Les modèles T4 sont géniaux, surtout lorsqu'ils sont combinés avec vos propres métadonnées et classes partielles.

Le modèle semble d'abord avoir beaucoup de potentiel, mais il me donne beaucoup de bugs au cours du refactoring de schéma de base de données complexe. Pas certain de pourquoi.


11
2017-09-27 04:16



Travailler avec de gros modèles était très lent avant le SP1, (ne l'ai pas essayé après le SP1, mais on dit que c'est un snap maintenant).

Je conçois toujours mes tables d'abord, puis un outil construit en interne génère les POCO pour moi, il prend donc la charge de faire des tâches répétitives pour chaque objet poco.

Lorsque vous utilisez des systèmes de contrôle de source, vous pouvez facilement suivre l'historique de vos POCO, ce n'est pas si simple avec le code généré par le concepteur.

J'ai une base pour mon POCO, ce qui rend beaucoup de choses assez faciles.

J'ai des vues pour toutes mes tables, chaque vue de base apporte des informations de base pour mes clés étrangères et ma vue POCOs dérive de mes classes POCO, ce qui est très utile à nouveau.

Et finalement je n'aime pas les designers.


6
2018-04-01 07:44



Exemple de première approche de base de données:

Sans écrire de code: Base de données ASP.NET MVC / MVC3 Première approche / base de données d'abord

Et je pense que c'est mieux que d'autres approches car la perte de données est moindre avec cette approche.


4
2018-03-10 03:33



IMHO Je pense que tous les modèles ont une bonne place, mais le problème que j'ai avec la première approche est dans beaucoup de grandes entreprises avec DBA contrôlant les bases de données que vous n'avez pas la possibilité de construire des applications sans utiliser les premières approches. J'ai travaillé sur de nombreux projets et quand il s'agissait de déploiement, ils voulaient un contrôle total.

Donc, autant que je suis d'accord avec toutes les variantes possibles Code d'abord, modèle d'abord, base de données d'abord, vous devez tenir compte de l'environnement de production réel. Donc, si votre système va être une application de base d'utilisateurs avec de nombreux utilisateurs et DBA en cours d'exécution de l'émission, vous pouvez considérer l'option de la base de données d'abord à mon avis.


3
2018-06-23 15:28