asp.net-mvc - EF 4 代码如何首先处理生产环境中的架构更改？

Question

传统上，我一直手工编写我的 sql 脚本，因此它们既漂亮又干净(我不喜欢生成的脚本)并发布到发布，我提供了一个全新的安装脚本和一个来自先前版本的迁移脚本，该脚本创建了新的表，修改已有的表等，这都相当标准。

我真的没有太多时间首先使用 EF 4 代码，但是如果它在生产环境中确实可行的话，我非常有兴趣使用它。

假设你有一个代码优先的方法，如果一个数据库不存在，将自动创建一个数据库。如果您发布具有架构/模型更改的软件的新版本，会发生什么。 EF 是否足够智能以更新数据库架构以匹配更新的 EF 模型？

场景

客户端安装的服务器上的asp.net MVC的网站。首次运行时，会创建一个全新的数据库

客户使用网站一段时间后，数据库中填充了一些数据

同时网站发布了新版本，EF模型发生了变化

客户端下载新版本，部署网站并指向现有数据库

代码首先只对初始部署有用，还是足够聪明来更新现有的数据库版本以发布这样的版本？

Answer 1

从 EF CTP4 开始，每次更改对象模型时都会删除并重新创建数据库(这不是默认约定，您必须通过设置数据库初始值设定项策略明确告诉 EF Code-First 这样做)。

话虽如此，EF 团队正在积极致力于 Database Evolution (aka Migrations) Solution这正是您的场景:一种解决方案，它将随着您的对象模型随时间变化而演变数据库架构，这实质上是尝试更改数据库以使其与您的模型同步，而不是重新创建它。

根据 EF 团队的说法，此功能将作为 EF 下一版本的一部分提供，该版本有望在 2011 年第一季度发布。