持续交付和数据库模式随实体框架变化
本文关键字：实体 框架 变化 模式 数据库 交付 | 更新日期: 2023-09-27 17:49:29
我们希望能够将我们的应用程序持续交付到生产环境中。我们目前部署到azure，使用表/blob存储，并有一个azure sql数据库，我们通过实体访问。
当数据库模式更改时，我们希望能够自动将模式更改应用到生产数据库，但由于这将在应用程序运行时发生，并且代码更改同时部署到许多节点上，因此我们不确定正确的方法是什么。
经过一些阅读似乎(这是有意义的)，应用程序需要容忍2个不同的数据库模式版本，所以它并不重要，如果它的代码的旧版本或新版本的代码看到数据库，但我不确定什么是最好的方法来处理这个应用程序是，使用实体框架。
我们是否应该在代码中对EF生成的类的实例进行版本控制，这些实例知道如何访问模式的特定版本?当模式更新并且旧版本的代码在数据库上运行时会发生什么情况?我们的实体框架类映射到数据库中特定模式的视图，没有映射到底层表，所以这可能允许我们创建旧代码使用的v1视图和新代码使用的v2视图，但是维护这感觉像是一场噩梦(仅仅维护EF映射到视图而不是表就已经够痛苦了)
那么这个领域的最佳实践是什么呢?其他人是怎么解决这个问题的?
无论您是否使用EF，维护代码与数据库的两个连续版本一起工作的能力是一个很好的(也许是唯一可行的)方法。
下面是我们处理特定类型迁移的一些方法:
-
当添加列时，我们通常可以只添加列(如果非空则使用默认约束)，而不用担心代码。EF永远不会发出"SELECT *"，因此它可以在忽略新列的情况下继续正常工作。同样，添加表也很容易。
-
在删除列或表时，只需将该列的时间保持在1个版本左右。
-
对于更复杂的迁移(例如完全改变数据模型的表或段的结构)，将新模型与向后兼容视图(或带有触发器以保持同步的表)一起部署，这些视图将与引用它们的代码一样存在。正如您所说，根据迁移的复杂性，这可能需要做很多工作，但听起来您已经做好了这样做的准备，因为您的EF实体无论如何都指向视图。另一方面，这项工作的好处是您有更多的时间来进行代码迁移。如果你有一个大的代码库，这可能是非常有益的，允许你迁移数据模型，以适应新功能的需求，同时仍然支持旧功能，而不需要重大的代码更改。
作为旁注，数据迁移的困难常常使我们将开发最终数据模型的时间尽可能地向后推。使用EF，您可以在数据模型最终确定之前编写和测试大量代码(我们在单元测试中使用代码优先来生成样例SQLExpress数据库，尽管我们的生产数据库不是通过代码优先来维护的)。这样，一旦新特性发布，我们就可以减少对生产数据模型的增量更改。