migrations de bases de données pour Entity Framework 4

Question

Je joue avec Entity Framework 4, en utilisant l'approche axée sur le modèle pour générer le script de base de données de mes entités. C'est très bien, mais je ne sais pas comment cela fonctionne quand il s'agit de versionner la base de données. Je devine que si je voulais utiliser un cadre de migration de type d'enregistrement actif je dois travailler dans l'autre sens et générer mes entités de ma base de données? Est-il possible d'utiliser l'approche axée sur le modèle et la version de la base de données correctement?

Answer 1

Ce sera bientôt un paquet NuGet appelé EntityFramework.Migrations

Une démo a été réalisée par Scott Hanselman à TechEd 2011 (disponible en ligne à http: //channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV349 ). La section pertinente est de 45 minutes.

En bref, une fois que le paquet est installé, vous entrez la commande suivante dans la console Package Manager pour générer un script de changement de base de données:

migrate -script

UPDATE (13-Nov-2011)

L'alpha 3 build de ce package est maintenant disponible sur NuGet. Plutôt que d'utiliser la migrate -script cmdlet mentionné ci-dessus, il utilise la Add-Migration <migrationname> cmdlet. A EntityFramework package NuGet , en commençant par la version 4.3. mis à jour sans rendez-vous grâce à l'aide EF 4.3 sont disponibles sur le blog de l'équipe ADO.NET.

Answer 2

Vous pouvez Wizardby : ceci est un outil de gestion des migrations de bases de données. Il ne s'intègre pas à EF (car il est presque impossible d'intégrer avec elle à cet égard), mais fait le travail.

Answer 3

ScottGu mentionne quelque chose à ce sujet dans un entrée de blog :

  

Nous allons également d'appuyer une « migration » caractéristique avec EF à l'avenir qui vous permettra d'automatiser / migrations de schéma de base de données de script par programme.

[EDIT]

Je pense qu'il pourrait faire référence à la Entité Designer Génération de base de données Power pack , comme une réponse par Morteza Manavi dans une autre réponse SO .

Answer 4

Eh bien, si vous voulez travailler comme ActiveRecord, alors vous devez travailler comme ActiveRecord. :)

Cependant, si vous voulez, mais toujours utiliser les migrations, ce sera possible, le premier modèle à utiliser, mais nécessitera un travail supplémentaire en votre nom. Modèle-première va générer un script de changement de base de données. Vous devrez extraire les parties pertinentes dans les migrations, ainsi que l'écriture manuelle undo scripts. Bien que cela implique un certain travail manuel, il ne me semble pas terriblement difficile.

Answer 5

Je travaille sur une alternative à la bibliothèque EF.Migrations - EntityFramework.SchemaCompare . Il permet de comparer physiquement un schéma db avec un modèle d'entités représentant le contexte de base de données (EF.Migrations ne le font pas). Cela peut être tiré lors de l'initialisation de la base de données ou manuellement sur demande. Prenons l'exemple suivant

#if DEBUG
Database.SetInitializer(new CheckCompatibilityWithModel<DatabaseContext>());
#endif

Il lancera une exception lors de l'initialisation de la base de données décrivant les différences entre le schéma db et le modèle si l'on trouve des problèmes d'incompatibilité. Vous pouvez également trouver ces différences à tout moment dans votre code de cette façon

using (var ctx = new DatabaseContext())
{
    var issues = ctx.Database.FindCompatibilityIssues();
}

Ensuite, ayant ces différences / problèmes d'incompatibilité sur les mains que vous pouvez mettre à jour le schéma db ou le modèle.

Cette approche est particulièrement utile lorsque vous avez besoin un contrôle complet sur la conception du schéma de base de données et le modèle et / ou travaillant dans une équipe où plusieurs membres de l'équipe travaillent sur le même schéma db et le modèle. Il peut également être utilisé en plus EF.Migrations.

me Fork à GitHub: https://github.com/kriasoft/data