Code-first vs Model/Database-first

Question

Quels sont les avantages et les inconvénients d'utiliser Entity Framework 4.1 Code-first plutôt que Model/Database-first avec un diagramme EDMX ?

J'essaie de bien comprendre toutes les approches pour construire une couche d'accès aux données avec EF 4.1. J'utilise le pattern Repository et IoC.

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

Je peux également créer un diagramme EDMX et choisir une étape de génération de code qui utilise des modèles T4 pour générer les mêmes classes POCO.

Dans les deux cas, je me retrouve avec des objets POCO qui sont agnostiques par rapport à ORM et un contexte qui dérive de DbContext .

Le principe de la base de données en premier semble être le plus attrayant car je peux concevoir la base de données dans Enterprise Manager, synchroniser rapidement le modèle et l'affiner à l'aide du concepteur.

Quelle est donc la différence entre ces deux approches ? S'agit-il uniquement d'une préférence entre VS2010 et Enterprise Manager ?

Answer 1

Je pense que les différences sont :

Code premier

• Très populaire parce que les programmeurs purs et durs n'aiment pas les concepteurs et que définir le mappage dans le xml EDMX est trop complexe.
• Contrôle total du code (pas de code généré automatiquement et difficile à modifier).
• On s'attend généralement à ce que vous ne vous préoccupiez pas de la DB. DB n'est qu'un stockage sans logique. EF s'occupera de la création et vous ne voulez pas savoir comment il fait son travail.
• Les modifications manuelles de la base de données seront très probablement perdues car votre code définit la base de données.

Base de données d'abord

• Très populaire si vous avez une base de données conçue par des DBA, développée séparément ou si vous avez une base de données existante.
• Vous laisserez EF créer des entités pour vous et après modification du mappage, vous générerez des entités POCO.
• Si vous voulez des fonctionnalité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 sont possibles car la base de données définit votre modèle de domaine. Vous pouvez toujours mettre à jour le modèle à partir de la base de données (cette fonctionnalité fonctionne très bien).
• Je l'utilise souvent avec les projets VS Database (uniquement version Premium et Ultimate).

Premier modèle

• IMHO populaire si vous êtes un fan de design (= vous n'aimez pas écrire du code ou du SQL).
• Vous allez "dessiner" votre modèle et laisser le workflow générer votre base de données script et le modèle T4 pour générer vos entités POCO. Vous perdrez une partie du contrôle sur vos entités et votre base de données mais pour des petits projets faciles vous serez très productif.
• Si vous voulez des fonctionnalité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 très probablement perdues car votre modèle définit la base de données. Cela fonctionne mieux si vous avez installé le pack de puissance de génération de base de données. Il vous permettra de mettre à jour le schéma de la base de données (au lieu de la recréer) ou de mettre à jour les projets de base de données dans VS.

Je m'attends à ce que dans le cas de EF 4.1, il y ait plusieurs autres fonctionnalités liées au Code First par rapport au Model/Database first. L'API fluide utilisée dans Code First n'offre pas toutes les fonctionnalités d'EDMX. Je m'attends à ce que des fonctionnalités comme le mappage des procédures stockées, les vues de requêtes, la définition des vues, etc. fonctionnent quand on utilise Model/Database first et DbContext (Je ne l'ai pas encore essayé) mais ils ne le font pas dans Code first.

Answer 2

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 :

Plus d'informations Ici .

Answer 3

Database first et model first n'ont 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 le designer, puis vous pouvez modifier la base de données en utilisant sql script et mettre à jour votre modèle.

Lorsque vous utilisez d'abord le code, vous ne pouvez pas modifier le modèle sans recréer la base de données et perdre toutes les données. IMHO, cette limitation est très stricte et ne permet pas d'utiliser le code first en production. Ce point sera abordé dans le prochain Migrations Microsoft Code First . Mais pour l'instant, il n'est pas vraiment utilisable.

Le deuxième inconvénient mineur du code premier est que le constructeur de modèles nécessite des privilèges sur la base de données principale. 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 premier code est un code très propre et simple. Vous avez le contrôle total de ce code et pouvez facilement le modifier et l'utiliser comme modèle de vue.

Je peux recommander d'utiliser l'approche "code first" lorsque vous créez une simple application autonome sans versionnement et en utilisant un modèle. \database d'abord dans les projets qui nécessitent une modification de la production.

Answer 4

3 raisons d'utiliser le code first design avec Entity Framework

1) Moins d'éléments inutiles, moins d'éléments superflus

L'utilisation d'une base de données existante pour générer un fichier modèle .edmx et les modèles de code associés donne lieu à un énorme tas de code généré automatiquement. Nous vous prions de ne jamais toucher à ces fichiers générés, de peur de casser quelque chose ou que vos modifications soient écrasées lors de la prochaine génération. Le contexte et l'initialisateur sont également mélangés dans cette pagaille. Lorsque vous avez besoin d'ajouter une fonctionnalité à vos modèles générés, comme une propriété calculée en lecture seule, vous devez étendre la classe du modèle. Cela finit par être une exigence pour presque tous les modèles et vous vous retrouvez avec une extension pour tout.

Avec le code first, vos modèles codés à la main deviennent votre base de données. Ce sont les fichiers exacts que vous construisez qui génèrent 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 extension de classe lorsque vous souhaitez ajouter des propriétés ou tout autre élément dont la base de données n'a pas besoin d'être informée. Vous pouvez simplement les ajouter dans la même classe tant que vous suivez la syntaxe appropriée. Si vous le souhaitez, vous pouvez même générer un fichier Model.edmx pour visualiser votre code.

2) Un meilleur contrôle

Lorsque vous optez pour la DB en premier, vous êtes à la merci de ce qui est généré pour vos modèles en vue de leur utilisation dans votre application. Parfois, la convention de dénomination n'est pas souhaitable. Parfois, les relations et les associations ne sont pas tout à fait ce que vous voulez. D'autres fois, les relations non transitoires avec chargement paresseux font des ravages dans vos réponses API.

Bien qu'il existe presque toujours une solution aux problèmes de génération de modèles que vous pouvez rencontrer, le fait de commencer par le code vous donne un contrôle complet et fin dès le départ. Vous pouvez contrôler chaque aspect de vos modèles de code et de la conception de votre base de données depuis le confort de votre objet d'entreprise. Vous pouvez spécifier avec précision les relations, les contraintes et les associations. Vous pouvez définir simultanément les limites de caractères des propriétés et la taille des colonnes de la base de données. Vous pouvez spécifier les collections liées qui doivent être chargées rapidement, ou ne pas être sérialisées du tout. En bref, vous êtes responsable d'un plus grand nombre de choses, mais vous gardez le contrôle total de la conception de votre application.

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

C'est un gros morceau. Le versionnement des bases de données est difficile, mais avec le code first et les migrations code first, c'est beaucoup plus efficace. Comme le schéma de votre base de données est entièrement basé sur vos modèles de code, en contrôlant la version de votre code source, vous aidez à versionner votre base de données. Vous êtes responsable du contrôle de l'initialisation de votre contexte, ce qui peut vous aider à faire des choses comme l'ensemencement de données commerciales fixes. Vous êtes également responsable de la création des premières migrations de code.

Lorsque vous activez les migrations pour la première fois, une classe de configuration et une migration initiale sont générées. La migration initiale est votre schéma actuel ou votre base de référence v1.0. À partir de ce moment, vous ajouterez des migrations qui seront horodatées et étiquetées avec un descripteur pour faciliter le classement des versions. Lorsque vous appelez add-migration depuis le gestionnaire de paquets, un nouveau fichier de migration sera généré contenant tout ce qui a changé dans votre modèle de code automatiquement dans une fonction UP() et DOWN(). La fonction UP applique les modifications à la base de données, la fonction DOWN supprime ces mêmes modifications dans le cas où vous souhaitez effectuer un retour en arrière. De plus, vous pouvez modifier ces fichiers de migration pour ajouter des changements supplémentaires tels que de nouvelles vues, index, procédures stockées et autres. Ils deviendront un véritable système de gestion des versions pour votre schéma de base de données.

http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework

Answer 5

Le code semble d'abord être l'étoile montante. J'ai jeté un coup d'œil rapide à Ruby on Rails, et leur norme est le code d'abord, avec des migrations de base de données.

Si vous construisez une application MVC3, je pense que Code first présente les avantages suivants :

• Décoration facile des attributs - Vous pouvez décorer les champs avec des attributs de validation, d'exigence, etc., mais la modélisation EF est assez maladroite.
• Pas d'erreurs de modélisation bizarres - La modélisation EF présente souvent des erreurs étranges, par exemple lorsque vous essayez de renommer une propriété d'association, elle doit correspondre aux métadonnées sous-jacentes - très peu flexible.
• Pas gênant de fusionner - Lorsque vous utilisez des outils de contrôle de version du code tels que mercurial, la fusion des fichiers .edmx est un véritable casse-tête. Vous êtes un programmeur habitué à C#, et vous vous retrouvez à fusionner un fichier .edmx. Ce n'est pas le cas avec le code-first.
• Si l'on compare avec le premier code, on a un contrôle total sans avoir à gérer toutes les complexités et les inconnues cachées.
• Je vous recommande d'utiliser l'outil en ligne de commande du gestionnaire de paquets, et de ne même pas utiliser les outils graphiques pour ajouter un nouveau contrôleur aux vues de l'échafaudage.
• Migrations DB - Ensuite, vous pouvez également activer les migrations. C'est très puissant. Vous apportez des modifications à votre modèle dans le code, puis le framework peut suivre les modifications du schéma, de sorte que vous pouvez déployer des mises à niveau de manière transparente, avec des versions de schéma automatiquement mises à niveau (et rétrogradées si nécessaire). (Je ne suis pas sûr, mais cela fonctionne probablement aussi avec le modèle d'abord).

Mise à jour

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

• Model-First : Codage des POCOs d'abord (le modèle conceptuel) puis générant la base de données (migrations) ; OU
• Base de données d'abord : Étant donné une base de données existante, manuellement en codant les POCOs pour qu'ils correspondent. (La différence ici étant que les POCOs ne sont pas générés automatiquement à partir de la base de données existante). Vous pouvez cependant vous rapprocher de l'automatique en utilisant Générer des classes POCO et le mapping pour une base de données existante en utilisant Entity Framework o Entity Framework 5 - Comment générer des classes POCO à partir d'une base de données existante .