0

在开发过程中，我喜欢像 Entity Framework 4.3 Migrations 这样的框架的想法（尽管我需要它来处理 sql 脚本而不是 Migration 类）使所有开发人员数据库保持最新。有人进行更新以获取最新源，他们尝试运行应用程序并收到错误，他们需要将数据库更新到最新迁移（或让迁移自动发生）。迁移文件带有时间戳，因此开发人员不必担心将两个文件命名为相同或文件需要执行的顺序。

当我准备构建 WebDeploy 部署包时，我希望该包包含将生产数据库移动到最新数据库版本所需的脚本。所以不知何故，MSBuild 或 WebDeploy 需要决定必须打包哪些脚本。对于部署，我不希望应用程序尝试像 EF 提供的那样更新自身。我想要么将包交给 IT 部门，要么通过部署服务器进行自动部署。

我的一些问题是：

  1. EF 4.3 是否可以使用 sql 脚本而不是 DBMigration 类来满足我的开发需求（我已经将它用于我的 ORM，所以如果可以的话会很好）？

  2. MSBuild 或 WebDeploy 是否理解数据库迁移的概念（例如，它是否识别 EF.4.3 migrationHistory 表）或者我是否必须确保只提供它需要运行的脚本，以便将我的 prod db 带到最新的迁移？手动决定应该打包哪些脚本不是我想做的事情，是否有理解迁移的 MS WebDeploy 扩展？

  3. 我的担忧和想法有效吗？我只是在研究这个东西，所以我真的不知道。

4

2 回答 2

2

我认为你的担忧是有道理的。在开发过程中，任何使开发人员机器保持同步的事情都可以做到。部署时，需要更多控制。

在我的项目中，我们决定只使用基于代码的迁移，以确保所有数据库都以相同的顺序和相同的步骤进行迁移。自定义初始化策略禁用自动迁移和数据库创建，该策略仅检查数据库是否存在且有效。

我在防止 EF 迁移创建或更改数据库中写了更多关于详细信息的内容。我还研究了一些最终会在多个开发人员身上发生的合并冲突。

于 2012-03-06T20:56:03.763 回答
0

  1. 您可以通过调用 Sql 方法在类中运行 SQL，或者通过使用带有 update-database 命令的 -script 参数从迁移中生成 SQL。

  2. 不，他们正在考虑增加对 webdeploy 的支持，但显然在 rtm 之前决定反对它。然而，他们确实发布了一个命令行应用程序（显然还有 powershell 脚本），您可以从中调用任何一个。

我在我的项目中所做的是在我的应用程序中创建一个启动模块并运行任何尚未自动部署的迁移 -在应用程序启动时通过代码触发 EF 迁移。这并不完美，开发人员必须在获取最新版本之后才能运行应用程序，然后才能更改数据库，但它适用于获取最新版本和部署。

于 2012-02-25T08:48:45.337 回答