c# - Entity Framework 的持续交付和数据库模式变化

Question

我们希望朝着能够将我们的应用程序持续交付到生产环境的方向前进。我们目前部署到 azure 并使用表/blob 存储并拥有一个 azure sql 数据库，我们通过实体访问它。

随着数据库架构的变化，我们希望能够自动将架构更改应用于生产数据库，但由于这将在应用程序处于事件状态时发生，并且代码更改同时部署到许多节点，我们不确定正确的方法是什么。

经过一些阅读之后，应用程序似乎(这是有道理的)需要容忍 2 个不同的数据库模式版本，因此无论是旧版本的代码还是新版本的代码都没有关系查看数据库的代码，但是我不确定在应用程序中处理此问题的最佳方法是使用实​​体框架。

我们是否应该在代码中对 EF 生成的类实例进行版本控制，以了解如何访问特定版本的架构？当架构更新并且旧版本的代码针对数据库运行时会发生什么？

我们的 Entity Framework 类被映射到数据库中特定模式的 View ，没有任何东西被映射到底层表，所以这可能允许我们创建旧代码使用的 v1 View 和新代码使用的 v2 View ，但是保持这种感觉就像是一场噩梦(仅仅维护 EF 映射到 View 而不是表就已经够痛苦了)

那么这方面的最佳实践是什么？其他人如何解决这个问题？

Answer 1

无论您是否使用 EF，保持代码与数据库的 2 个连续版本一起工作的能力是一种很好的(也许是唯一可行的)方法。

以下是我们处理特定类型迁移的一些方法:

• 添加列时，我们通常可以只添加列(如果不可为空则使用默认约束)而不用担心代码。 EF 永远不会发出“SELECT *”，因此它将能够在忽略新列的同时继续正常运行。同样，添加表格也很容易。

• 删除列或表时，只需将该列保留大约 1 个版本即可。

• 对于更复杂的迁移(例如，完全更改表或数据模型段的结构)，将新模型与向后兼容的 View (或带有触发器以保持同步的表)一起部署，这将与引用它们的代码一样长寿。正如您所说，这可能需要大量工作，具体取决于迁移的复杂性，但听起来您已经准备好执行此操作，因为您的 EF 实体无论如何都指向 View 。另一方面，这项工作的好处是您有更多时间进行代码迁移。如果您有一个大型代码库，这可能非常有益，因为它允许您迁移数据模型以满足新功能的需求，同时仍然支持旧功能而无需进行重大代码更改。

附带说明一下，数据迁移的困难常常使我们在开发计划中尽可能早地推进最终数据模型的开发。使用 EF，您可以在数据模型最终确定之前编写和测试大量代码(我们使用代码优先在单元测试中生成示例 SQLExpress 数据库，即使我们的生产数据库不是由代码优先维护的)。这样，一旦发布新功能，我们对生产数据模型所做的增量更改就会更少。