c# - 用 Entity Framework 和 POCO 类替换遗留数据层的策略

Question

我们正在处理的这个项目中使用 .net C# 4.0、VS 2010、EF 4.1 和遗留代码。

我正在开发一个 win 表单项目，我决定开始使用 Entity Framework 4.1 来访问 ms sql 数据库。代码库很旧，我们有一个使用数据适配器的现有数据层。这些数据适配器到处都在使用(在 Web 应用程序和 Win Form 应用程序中)我的计划是随着时间的推移用 EF 替换旧的数据库访问代码，并摆脱 UI 层和数据层之间的紧密耦合。

因此，我的想法是或多或少地将 EF 与遗留数据访问层相结合，并使用 EF 以更现代的方式慢慢取代遗留数据层。所以现在我们需要同时使用 EF 和遗留数据库访问代码。

到目前为止，我所做的是添加一个包含 edmx 文件和上下文的项目。 edmx 是使用数据库优先方法生成的。我还添加了另一个包含 POCO 类的项目(通过使用 ADO.NET POCO 实体生成器)。我或多或少地遵循了 Julia Lerman 在她的“Programming Entity Framework”一书中关于如何拆分模型和生成的 POCO 类的方法。数据库模型已经设置多年，更改表和关系、触发器、存储过程等不是一个选项，所以我基本上坚持使用数据库模型。

我已经阅读了有关存储库模式和工作单元的内容，我有点喜欢这些模式，但是当我同时需要处理 EF 和遗留数据库访问代码时，我很难实现它们。特别是当我没有时间用纯 EF 实现替换所有遗留数据库访问代码时。在一个完美的世界中，我会使用全新的数据模型重新开始，但这不是一个选项。

这里是存储库和工作单元模式吗？为了在我的业务层中使用 POCO 类，有时我需要同时使用 EF 和遗留数据库代码来填充我的 POCO 类。换句话说，有时我可以使用 EF 检索我需要的一部分数据，并使用旧的数据库访问层检索其余数据，然后将数据映射到我的 POCO 类。当我想更新一些数据时，我需要从 POCO 类中选取数据并使用遗留数据访问代码将数据存储在数据库中。因此，当我想在 UI 中显示数据时，我需要将从遗留数据访问层检索到的数据映射到我的 POCO 类，反之亦然，当我想将数据保存到数据库时。

为了使事情复杂化，我们将一些数据存储在我们在运行前不知道其名称的表中(请不要问我为什么:-))。因此，在旧的数据库访问层中，我们必须根据其他表的信息在插入表名和列名的位置动态创建 sql 语句。

我还发现 POCO 类之间的关系有点过于以数据库为中心。换句话说，我觉得我需要有一个更简化的领域模型来使用。也许我应该创建一个符合要求的域模型，然后将 POCO 类用作“DAO”来填充域模型类？

您将如何使用存储库模式和工作单元模式来实现它？ (如果这是要走的路)

Answer 1

警钟在为我敲响!我们不久前尝试做类似的事情(仅使用 nHibernate 而不是 EF4)。我们在与 ORM 一起运行 ADO.NET 时遇到了几个问题——数据库并发性是一个大问题。

The database model has been set for years and it's not an option the change the table and the relationships, triggers, stored procedures, etc, so I'm basically stuck with the db model as it is.

是的。一样!问题是我们的存储过程包含很多业务逻辑并且不是简单的 CRUD 过程，因此通过存储过程执行的各种更新来保持 ORM 更新一点也不容易——单一责任原则——不是一个好的打破!

My plan is to replace the old db access code with EF over time and get rid for the tight coupling
between UI layers and data layer.

也许您可以在不需要 ORM 的情况下解耦 - 如何在您的 UI 层前面放置一个服务/外观层来协调与底层域的所有交互并将其隐藏在 UI 中。

如果您的数据库是“王者”并且您的应用程序是高度数据驱动的，我认为您将始终在实现您提到的模式时打一场艰苦的战斗。

为这个项目拥抱 ado.net - 在你的下一个绿色领域项目中使用 EF4 和 DDD 模式 :)