我正在考虑在即将推出的项目中使用 Microsoft 的实体框架,该项目是现有产品的点发布。我们当前的产品支持两个 DBMS(Oracle 和 SQL Server),每个的架构都保存在单独的 .sql 脚本文件中。
实体框架 (4.1) 看起来很吸引人,因为它允许通过代码生成、反射等自动实现各种场景。但是,据我所知,其中一些好处似乎是相互排斥的。
例如,为了支持多个 DMBS,我推断我需要使用模型或代码优先设计,在这种情况下,EF 将根据模型为每个 DMBS 生成模式(我几乎没有看到关于此的帖子或文档,所以我可能是错的)。这意味着我们现有的模式需要被放弃(模型优先)或映射(代码优先)。此外,更新架构需要手动脚本,因为 EF 似乎不支持架构升级(不清除数据)。
- 模型优先和代码优先是在 EF 中支持多个 DBMS 的唯一可行方法吗?我意识到从技术上讲,不可能保证两个任意模式是相同的,所以我认为这是真的。
- 代码优先和映射到多个 DBMS 系统是否存在任何潜在缺陷?例如,Oracle 没有自增列;你必须使用序列。这在 DbContext 中是如何映射的?我需要为每个 DBMS 创建单独的映射吗?
- EF 是否支持将现有 DBMS 模式升级到代表 EF 模型的任何机制(模式重新创建 =/= 升级),或者我是否仅限于手动执行此操作?
- 我确实想出了一种可能的方法来首先使用数据库并支持多个 DBMS,但这是维护的噩梦。这个想法是为两个生成的数据模型添加另一层抽象,并为每个 EF 生成的模型创建转换器类。这似乎是最好的方法,这样每个 DBMS 都可能有自己的模型,但我的代码将处理映射。但在这样做的过程中,我真正从 EF 中获得了什么?也许查询生成,但这值得吗?