Code-premier vs modèle/base de données-premier

je pense que ce simple "arbre de décision" par Julie Lerman l'auteur de la Programmation "Entity Framework" devrait aider à la prise de décision avec plus de confiance:

Plus d'infos Ici .

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 la 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.

quand 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. IMHO, cette limitation est très stricte et ne permet pas d'utiliser le code en premier dans la production. Pour l'instant, il n'est pas vraiment utilisable.

Second inconvénient mineur du premier code est que le constructeur de modèles ont besoin de privilèges sur la base de données principale. Cela ne vous affecte pas si vous utilisez la base de données compacte de SQL Server ou si vous contrôlez le serveur de base de données.

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

je peux vous recommander d'utiliser le code première approche lorsque vous créez application autonome simple sans versioning et utilisant d'abord model\database dans les projets qui nécessitent des modifications 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 le code first design avec Entity Framework

1) moins cruft, moins bloat

utilisant une base de données existante pour générer un .edmx fichier de modèle et le les modèles de code associés donnent 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 que vous ne cassez quelque chose, ou vos changements seront écrasés sur la génération suivante. Le contexte et d'initialiseur sont coincés ensemble dans cette galère. Lorsque vous devez ajouter des fonctionnalités à vos modèles générés, comme un propriété calculée en lecture seule, 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. La 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 les 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 quoi que ce soit d'autre que la base de données n'a pas besoin d'en connaître. Vous pouvez simplement les ajouter dans la même classe aussi longtemps que vous suivez la bonne syntaxe. Heck, vous pouvez même générer un Modèle.edmx pour visualiser votre code si vous vouloir.

2) Contrôle Accru

quand vous allez DB en premier, vous êtes à la merci de ce qui est généré pour vos modèles à utiliser dans votre application. De temps en temps le nommage la convention n'est pas souhaitable. Parfois, les relations et les les associations ne sont pas ce que vous voulez. Autres temps non transitoires les relations avec les chargements paresseux font 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, going code first vous donne complet et bien contrôle grainé dès le début. Vous pouvez contrôler tous les aspects des deux vos modèles de code et votre conception de base de données à partir du confort de votre objet de l'entreprise. Vous pouvez spécifier précisément les relations, les contraintes, et les associations. Vous pouvez définir simultanément les limites de caractères d'une propriété et la base de données de tailles de colonne. Vous pouvez spécifier quelles collections liées sont impatients chargé, ou ne pas être sérialisé. En bref, vous êtes responsable de plus de choses, mais vous êtes en plein contrôle de votre application conception.

3) Contrôle De La Version De La Base De Données

C'est un grand. Versionner des bases de données est difficile, mais avec le code d'abord et coder d'abord les 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 aidez à la version de votre base de données. Vous êtes responsable du contrôle de l'initialisation de votre contexte peut vous aider à faire des choses comme la graine fixe d'affaires données. Vous êtes également responsable de la création des premières migrations de code.

lorsque vous activez pour la première fois les migrations, une classe de configuration et une initiale la migration est générée. La migration initiale est votre schéma actuel ou votre ligne de base v1.0. A partir de là, vous allez ajouter des migrations qui sont timestampés et étiquetés avec un descripteur pour aider avec la commande de versions. Lorsque vous appelez add-migration depuis le paquet Gestionnaire, un nouveau fichier de migration sera généré contenant tout qui a changé dans votre modèle de code automatiquement dans un UP() et Vers le BAS() fonction. La fonction s'applique les modifications à la base de données, la fonction de bas supprime ces mêmes changements dans le cas où vous voulez rollback. De plus, vous pouvez éditer ces fichiers de migration pour ajouter d'autres changements tels que de nouvelles vues, des index, les procédures stockées et les que ce soit d'autre. Ils deviendront un véritable système de versioning pour votre schéma de base de données.

Code-première semble être l'étoile montante. J'ai jeté un coup d'oeil à Ruby on Rails, et leur standard est code-first, avec des migrations de base de données.

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

• easy attribut decoration - vous pouvez décorer les champs avec validation, require, etc..
• No weird modelling errors - la modélisation EF comporte souvent des erreurs bizarres, 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 maladroit de fusionner - en utilisant des outils de contrôle de version de code tels que mercurial, merging .edmx fichiers est une douleur. Vous êtes un programmeur habitué à C#, et là vous fusionnez A.edmx. Pas avec code-première.
• contraste retour au Code d'abord et vous avez le contrôle complet sans toutes les complexités cachées et inconnues à traiter.
• je vous recommande d'utiliser L'outil en ligne de commande Package Manager, n'utilisez même pas les outils graphiques pour ajouter un nouveau contrôleur aux vues scaffold.
• DB-Migrations - alors vous pouvez également activer-Migrations. C'est tellement puissant. Vous faites des changements à votre modèle dans le code, et alors le cadre peut garder la trace des changements de schéma, vous pouvez donc déployer des mises à jour sans problème, avec des versions de schéma automatiquement mises à jour (et déclassées si nécessaire). (Pas sûr, mais cela n'a probablement travailler avec le modèle de premier trop)

mise à Jour

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

• Modèle-premier : codage de la POCOs en premier (modèle conceptuel), puis génération la base de données (migrations); OU
• Database-First : étant donné une base de données existante, manuellement codant les POCOs pour correspondre. (La différence ici étant que les POCOs ne sont pas automatiquement générés donner alors la base de données existante). Vous pouvez vous rapprocher de l'automatique mais en utilisant générer des classes POCO et la cartographie pour une base de données existante à l'aide de Entity Framework ou Entity Framework 5 - Comment générer des classes POCO à partir de la base de données existante .

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.

EF code d'abord et le modèle d'abord semblait cool au début, et fournit l'indépendance de base de données, mais en faisant cela, il ne vous permet pas de spécifier ce que je considère très basique et commune informations de configuration de base de données. Par exemple, les index de table, les métadonnées de sécurité, ou ont une clé primaire contenant plus d'une colonne. Je trouve que je veux les utiliser d'autres fonctionnalités de base de données communes et doivent donc de toute façon faire une configuration de base de données directement.

je trouve que les classes de POCO par défaut générées pendant DB first sont très propres, cependant manquent les attributs d'annotation de données très utiles, ou les 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 premier Modèle semble avoir beaucoup de potentiel, mais me donne beaucoup de bugs pendant le remaniement de schéma de base de données complexe. Je ne sais pas pourquoi.

travailler avec de grands modèles était très lent avant la SP1, (ne l'ont pas essayé après la SP1, mais il est dit que c'est un snap maintenant).

je continue à concevoir mes tables d'abord, puis un outil maison construit génère les POCOs 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 source, vous pouvez facilement suivre l'historique de vos POCOs, il n'est pas si facile 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érivent de mes classes de POCO, qui est assez utile à nouveau.

et enfin je n'aime pas les designers.

première approche de la Base de données exemple:

sans écrire de code: ASP.NET MVC / MVC3 Database First Approach / Database first

et je pense que c'est mieux que d'autres approches parce que 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 le modèle première approche est dans de nombreuses grandes entreprises avec DBA contrôler les bases de données, vous ne obtenez pas la flexibilité de construire des applications sans utiliser la base de données premières approches. J'ai travaillé sur de nombreux projets et lorsqu'il s'est agi du déploiement, ils voulaient le plein contrôle.

donc autant que je suis d'accord avec toutes les variations possibles Code D'abord, modèle D'abord, base de données d'abord, vous doit considérer l'environnement de production réel. Donc, si votre système va être une grande application de base de l'utilisateur avec de nombreux utilisateurs et DBA exécute le spectacle, alors vous pourriez considérer la base de données première option juste mon avis.