Code-premier vs modèle / base de données-premier
Quels sont les avantages et les inconvénients de l'utilisation d'Entity Framework 4.1 Code-d'abord sur Modèle/Base de données avec le diagramme EDMX?
J'essaie de bien comprendre toutes les approches de la construction d'une couche d'accès aux données avec EF 4.1. J'utilise un modèle de référentiel et IoCname__.
Je sais que je peux utiliser l'approche du code d'abord: définir mes entités et mon contexte à la main et utiliser ModelBuilderpour affiner le schéma.
Je peux également créer un diagramme EDMXet choisir une étape de génération de code utilisant des modèles T4 pour générer les mêmes classes POCOname__.
Dans les deux cas, je me retrouve avec un objet POCOqui est ORMet un contexte dérivé de DbContextname__.
Database-first semble le plus séduisant, car je peux concevoir une base de données dans Enterprise Manager, synchroniser rapidement le modèle et le peaufiner à l'aide du concepteur.
Alors, quelle est la différence entre ces deux approches? S'agit-il uniquement de la préférence VS2010 par rapport à Enterprise Manager?
Je pense que les différences sont les suivantes:
Code d'abord
- Très populaire parce que les programmeurs hardcore n'aiment aucun type de concepteur et que définir un mappage dans EDMX xml est trop complexe.
- Contrôle total sur le code (pas de code généré automatiquement et difficile à modifier).
- L'attente générale est que vous ne vous occupez pas de DB. La base de données n'est qu'un stockage sans logique. EF se chargera de 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 en premier
- Très populaire si vous avez une base de données conçue par des administrateurs de base de données, 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 souhaitez des fonctionnalités supplémentaires dans les entités POCO, vous devez soit modifier le modèle, soit utiliser des classes partielles.
- Des modifications manuelles de la base de données sont possibles car celle-ci 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 ensemble ces projets VS Database (uniquement les versions Premium et Ultimate).
Modèle d'abord
- IMHO populaire si vous êtes fan de concepteur (= vous n'aimez pas écrire du code ou SQL).
- Vous allez "dessiner" votre modèle et laisser le flux de travail générer votre script de base de données et le modèle T4 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 vous serez très productif pour de petits projets simples.
- Si vous souhaitez des fonctionnalités supplémentaires dans les entités POCO, vous devez soit modifier le modèle, 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 générateur de base de données. Il vous permettra de mettre à jour le schéma de base de données (au lieu de le recréer) ou de mettre à jour des projets de base de données dans VS.
Je suppose que dans le cas de EF 4.1, il y a plusieurs autres fonctionnalités liées à Code d'abord par rapport à 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 des procédures stockées, les vues de requête, la définition de vues, etc. fonctionnent lorsque vous utilisez d'abord Modèle/Base de données et DbContext (je ne l'ai pas encore essayé), mais pas dans Code en premier.
Je pense que ce simple "arbre de décision" de Julie Lerman, l'auteur de "Programming Entity Framework", devrait aider à prendre une décision plus confiante:
Plus d'infos ici .
La base de données en premier et le modèle en premier n'ont pas de réelle différence. 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 à l'aide de designer, puis modifier celle-ci à l'aide d'un script SQL et mettre à jour votre modèle.
Lorsque vous utilisez d’abord le code, vous ne pouvez pas modifier le modèle sans une base de données de loisirs et la perte de toutes les données. IMHO, cette limitation est très stricte et ne permet pas d'utiliser du 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 a besoin de privilèges sur la base de données master. Cela ne vous concerne pas si vous utilisez une 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 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 d'abord le code lorsque vous créez une application autonome simple sans versioning et utilisez d'abord model\database dans les projets nécessitant une modification en production.
Citant les parties pertinentes de http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework
3 raisons d'utiliser la première conception de code avec Entity Framework
1) Moins cruel, moins gonflement
L'utilisation d'une base de données existante pour générer un fichier de modèle .edmx et les modèles de code associés génère une pile de code générée automatiquement. Vous êtes imploré de ne jamais toucher à ces fichiers générés de peur que quelque chose ne se casse ou que vos modifications ne soient écrasées à la prochaine génération. Le contexte et l'initialiseur sont également coincés dans ce désordre. Lorsque vous devez ajouter des fonctionnalités à vos modèles générés, comme une 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 vous retrouvez avec une extension pour tout.
Avec le code d'abord, 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 que la base de données n'a pas besoin de connaître. Vous pouvez simplement les ajouter dans la 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) Contrôle accru
Lorsque vous commencez à utiliser DB, vous êtes à la merci de ce qui est généré pour vos modèles et utilisé dans votre application. Parfois, la convention de dénomination est indésirable. Parfois, les relations et les associations ne sont pas tout à fait ce que vous voulez. D'autres fois, les relations non transitoires avec le chargement paresseux font des ravages dans les réponses de votre API.
Bien qu'il existe presque toujours une solution aux problèmes de génération de modèles que vous pouvez rencontrer, le code initial vous donne un contrôle complet et fin dès le départ. Vous pouvez contrôler tous les aspects de vos modèles de code et de la conception de votre base de données depuis le confort de votre objet métier. Vous pouvez spécifier avec précision des relations, des contraintes et des associations. Vous pouvez simultanément définir des limites de caractères de propriété et des tailles de colonne de base de données. Vous pouvez spécifier quelles collections associées doivent être chargées avec précaution ou ne pas être sérialisées du tout. En bref, vous êtes responsable de plus de contenus, mais vous contrôlez totalement la conception de votre application.
3) Contrôle de version de la base de données
C'est un gros. La gestion des bases de données est difficile, mais avec le code avant et après les migrations, elle est beaucoup plus efficace. Parce que votre schéma de base de données est entièrement basé sur vos modèles de code, en contrôlant la version de votre code source, vous contribuez à la version de votre base de données. Vous êtes responsable du contrôle de votre initialisation de contexte, ce qui peut vous aider à effectuer des tâches telles que l’amorçage 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 version de base v1.0. À partir de ce moment, vous ajouterez des migrations horodatées et étiquetées avec un descripteur facilitant la commande des versions. Lorsque vous appelez add-migration à partir du gestionnaire de packages, un nouveau fichier de migration contenant tout ce qui a été modifié dans votre modèle de code sera automatiquement généré dans les fonctions UP () et DOWN (). La fonction UP applique les modifications à la base de données, la fonction DOWN supprime ces mêmes modifications dans l'événement que vous souhaitez annuler. De plus, vous pouvez modifier ces fichiers de migration pour ajouter des modifications supplémentaires, telles que de nouvelles vues, des index, des procédures stockées, etc. Ils deviendront un véritable système de gestion de versions pour votre schéma de base de données.
Le code d'abord semble être l'étoile montante. J'ai jeté un coup d'œil à Ruby on Rails, et leur norme est d'abord basée sur le code, avec les migrations de bases de données.
Si vous construisez une application MVC3, je pense que Code présente d'abord les avantages suivants:
- Décoration d'attribut facile - Vous pouvez décorer des champs avec des attributs de validation, Requise, etc., c'est assez gênant avec la modélisation EF
- Aucune erreur de modélisation étrange - La modélisation EF comporte 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 inflexible.
- Fusion difficile - Lorsque vous utilisez des outils de contrôle de version de code tels que Mercurial, la fusion de fichiers .edmx est une tâche ardue. Vous êtes un programmeur habitué à C # et vous fusionnez un .edmx. Ce n'est pas le cas avec le code d'abord.
- Commencez par contraste avec Code et vous aurez un contrôle complet sans toutes les complexités cachées et les inconnus à traiter.
- Je vous recommande d'utiliser l'outil de ligne de commande du gestionnaire de packages. N'utilisez même pas les outils graphiques pour ajouter un nouveau contrôleur afin d'afficher des vues.
- DB-Migrations - Vous pouvez également activer/désactiver les migrations. C'est tellement puissant. Vous modifiez votre modèle dans le code, puis la structure peut suivre les modifications de schéma afin de déployer des mises à niveau de manière transparente, les versions de schéma étant automatiquement mises à niveau (et rétrogradées si nécessaire). (Pas sûr, mais cela fonctionne probablement avec le modèle d'abord aussi)
Mettre à jour
La question demande également une comparaison du code d'abord avec le modèle EDMX/db-first. Code-first peut également être utilisé pour les deux approches suivantes:
- Model-First : Coder d'abord les POCO (le modèle conceptuel) puis générer la base de données (migrations) ; OU
- Database-First : à partir d'une base de données existante, codant manuellement les POCO afin qu'ils correspondent. (La différence ici étant que les POCO ne sont pas générés automatiquement donnent alors la base de données existante). Vous pouvez être presque automatique en utilisant Générer des classes POCO et le mappage d'une base de données existante à l'aide d'Entity Framework ou Entity Framework 5 - Comment générer des classes POCO à partir d'une base de données existante .
J'utilise d'abord la base de données EF afin d'offrir plus de flexibilité et de contrôle sur la configuration de la base de données.
Le code EF en premier et le modèle semblaient d’abord sympas au premier abord et offraient l’indépendance de la base de données. Toutefois, cela ne vous permet pas de spécifier les informations que je considère très simples et très courantes sur la configuration de la base de données. Par exemple, les index de table, les métadonnées de sécurité ou une clé primaire contenant plusieurs colonnes. Je trouve que je veux utiliser ces fonctions et d'autres fonctionnalités communes de la base de données et que je dois donc faire une configuration de base de données directement de toute façon.
Je trouve que les classes POCO par défaut générées lors de la première base de données sont très propres, mais manquent des attributs très utiles d'annotation de données ou de mappages sur des 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.
Model semble avoir beaucoup de potentiel, mais me donne beaucoup de bogues lors du refactoring de schéma de base de données complexe. Pas certain de pourquoi.
Travailler avec de grands modèles était très lent avant le SP1, (je ne l'ai pas essayé après le SP1, mais on dit que c'est un jeu d'enfant maintenant).
Je conçois toujours mes tables en premier, puis un outil construit en interne génère les POCO pour moi, de sorte qu'il est fastidieux 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 facile avec le code généré par le concepteur.
J'ai une base pour mon POCO, ce qui facilite beaucoup de choses.
J'ai des vues pour toutes mes tables, chaque vue de base apporte des informations de base pour mes clés étrangères et mes vues POCO proviennent de mes classes POCO, ce qui est à nouveau très utile.
Et finalement je n'aime pas les designers.
Exemple de première approche de base de données:
Sans écrire de code: ASP.NET MVC/MVC3 base première approche/base première
Et je pense que c'est mieux que les autres approches car la perte de données est moins avec cette approche.
IMHO Je pense que tous les modèles ont une bonne place mais le problème que j'ai avec l'approche du modèle d'abord est dans beaucoup de grandes entreprises avec DBA contrôlant les bases de données vous n'obtenez pas la flexibilité de créer des applications sans utiliser les approches de base de données. J'ai travaillé sur de nombreux projets et, lors du déploiement, ils souhaitaient un contrôle total.
Donc, même si je suis d’accord avec toutes les variations 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 doit être une application de base avec de nombreux utilisateurs et administrateurs de base de données exécutant l'émission, vous pouvez envisager la première option de base de données, à mon avis.