实体框架 4 的数据库迁移
我一直在使用 Entity Framework 4,使用模型驱动方法从我的实体生成数据库脚本。这很棒,但我不确定在数据库版本控制方面它是如何工作的。我猜如果我想使用活动记录类型迁移框架,我必须以相反的方式工作并从数据库生成我的实体?有没有办法使用模型驱动方法并正确版本数据库?
I've been playing with Entity Framework 4, using the model driven approach to generate the database script from my entities. This is great but I'm not sure how this works when it comes to versioning the database. I'm guessing if I wanted to use an active record type migration framework I'd have to work the other way around and generate my entities from my database? Is there any way to use the model driven approach and version the database properly?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
即将推出名为 EntityFramework.Migrations 的 NuGet 包
Scott Hanselman 在 TechEd 2011 上进行了演示(可在线访问 http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV349)。相关部分的时长为 45 分钟。
简而言之,安装软件包后,您将在软件包管理器控制台中输入以下内容以生成数据库更改脚本:
更新 (2011 年 11 月 13 日)
该包的 alpha 3 版本现已在 NuGet 上提供。它没有使用上面提到的 cmdlet
migrate -script
,而是使用 cmdletAdd-Migration
。 其使用演练可以在 ADO.NET 团队博客上找到。更新(2012 年 2 月 14 日)
此功能现已作为主要 EntityFramework NuGet 的一部分提供包,从版本 4.3 开始。可以在 ADO.NET 团队博客上找到使用 EF 4.3 的更新的演练。
This will be coming soon as a NuGet package called EntityFramework.Migrations
A demo was performed by Scott Hanselman at TechEd 2011 (available online at http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV349). The relevant section is 45 minutes in.
In short, once the package is installed, you'll enter the following into the Package Manager Console to generate a database change script:
UPDATE (13-Nov-2011)
The alpha 3 build of this package is now available on NuGet. Rather than use the cmdlet
migrate -script
mentioned above, it uses the cmdletAdd-Migration <migrationname>
. A walk-through of its use can be found on the ADO.NET team blog.UPDATE (14-Feb-2012)
This functionality is now available as part of the main EntityFramework NuGet package, starting with version 4.3. An updated walk-through using EF 4.3 can be found on the ADO.NET team blog.
您可以尝试 Wizardby:这是一个用于管理数据库迁移的工具。它不与 EF 集成(因为在这方面几乎不可能与 EF 集成),但可以完成这项工作。
You can try Wizardby: this is a tool for managing database migrations. It doesn't integrate with EF (since it's nearly impossible to integrate with it in this respect), but does the job.
ScottGu 在 博客条目:
[编辑]
我认为他可能指的是 实体设计器数据库生成Power Pack,正如 Morteza Manavi 在 另一个SO答案。
ScottGu mentions something about this in a blog entry:
[EDIT]
I think he might be referring to the Entity Designer Database Generation Power Pack, as answered by Morteza Manavi in another SO answer.
好吧,如果您想像 ActiveRecord 一样工作,那么您需要像 ActiveRecord 一样工作。 :)
但是,如果您想使用模型优先但仍使用迁移,这是可能的,但需要您进行额外的工作。 Model-first 将生成数据库更改脚本。您必须将相关部分提取到迁移中,并手动编写撤消脚本。虽然这涉及一些体力劳动,但我觉得并不是非常困难。
Well, if you want to work like ActiveRecord, then you need to work like ActiveRecord. :)
However, if you want to use model-first but still use migrations, this will be possible, but will require extra work on your behalf. Model-first will generate a database change script. You will have to extract the relevant parts into migrations, as well as manually writing undo scripts. Although this involves some manual labor, it doesn't strike me as terribly difficult.
我正在研究 EF.Migrations 库的替代方案 - EntityFramework.SchemaCompare。它允许将数据库模式与表示数据库上下文的实体模型进行物理比较(EF.Migrations 不这样做)。这可以在数据库初始化期间触发,也可以根据请求手动触发。考虑以下示例,
如果发现不兼容问题,它将在数据库初始化期间抛出异常,描述数据库模式和模型之间的差异。或者,您可以通过这种方式随时在代码中找到这些差异,
然后遇到这些差异/不兼容问题,您可以更新数据库架构或模型。
当您需要完全控制数据库架构和模型设计和/或在多个团队成员处理同一数据库架构和模型的团队中工作时,此方法特别有用。除了 EF.Migrations 之外,它还可以使用。
在 GitHub 上分叉我:https://github.com/kriasoft/data
I'm working on an alternative to EF.Migrations library - EntityFramework.SchemaCompare. It allows to physically compare a db schema with an entities model representing database context (EF.Migrations doesn't do it). This can be fired either during database initialization or manually on request. Consider the following example
It will throw an exception during database initialization describing the differences between db schema and model if incompatibility issues are found. Alternatively you can find those differences at any time in your code this way
Then having those differences / incompatibility issues on hands you can either update the db schema or the model.
This approach is particularly useful when you need complete control over the database schema and model design and/or working in a team where multiple team members are working on the same db schema and model. It can also be used in addition to EF.Migrations.
Fork me at GitHub: https://github.com/kriasoft/data