0

我想对这个问题提出一些建议：我们有一个使用经典ADO.NET数据访问的解决方案（它已经有 4 年以上的历史了）。数据访问体系结构已经建立在.NET 2.0. 我们的数据类是简单的类，例如，FooDataBaseObject（名称实际上并不重要），它具有 CRUD 操作的默认实现。我们的属性标有自定义属性（保存必要的数据，例如表中相应列的名称等）。数据类也是如此（自定义属性用于指定表名等）。

实体之间的关系在特殊的 .xsd 和 .xml 文件中指定。表本身很少有外键和其他典型约束（我们实际上继承了这个表，客户禁止我们修改它们，因为它们仍然使用导入和导出引擎）。但我确信我能够说服人们重构数据库。

问题在于现有服务。有没有办法引入 EF 仍然可以使用旧的 ado.net 服务？我目前正在考虑使用EF Code First方法的想法，因为我不需要生成我的实体或继承某些特定的类等，而不是我将能够（我希望）DbContext为它们构造一个并映射到现有的数据库。此外，可能还有一种方法可以为我们的旧数据类创建镜像类。说Customer-> CustomerEntity。CustomerEntity将镜像 the 的所有必要属性，Customer然后在DbContextand中使用DbSet，这样我们就可以CustomerEntity在新服务中使用，也可以Customer在旧服务中使用。

我想听听这种方法的潜在瓶颈以及这种可能性的可能性（这真的是真的吗？）或者其他一些建议等。谢谢！

4

1 回答 1

1

如果表没有外键关系，使用 EF 会遇到很多问题。EF 通常会依赖这些关系来在代码中创建关系。

当然，您可以将它们视为单独的表 -> 单独的对象并手动处理所有键。

您不太可能在不修改的情况下将类映射到旧代码，因为旧代码似乎依赖于它自己的辅助方法以及提交或回滚数据的方式。在不了解现有对象模型的情况下，很难说。

我要做的是创建一个 EF 模型，然后在升级应用程序时开始逐步使用它。只要您现有的代码孤立地处理事物，并且整个代码没有太多的依赖关系。

于 2012-09-22T19:34:08.613 回答