使用Entity框架和POCO类替换遗留数据层的策略

Question

我们正在使用.net C#4.0,VS 2010,EF 4.1和遗留代码.

我正在开展一个win form项目,我决定开始使用实体框架4.1来访问ms sql db.代码库很旧,我们有一个使用数据适配器的现有数据层.这些数据适配器遍布各处(在web应用程序和win form应用程序中)我的计划是随着时间的推移用EF替换旧的db访问代码,并摆脱UI层和数据层之间的紧密耦合.

因此,我的想法是或多或少地将EF与遗留数据访问层相结合,并使用EF更加现代地利用EF来缓慢替换旧数据层.所以现在我们需要使用EF和遗留数据库访问代码.

到目前为止我所做的是添加一个包含edmx文件和上下文的项目.edmx是使用数据库第一种方法生成的.我还添加了另一个包含POCO类的项目(通过使用ADO.NET POCO实体生成器).我或多或少地在她的"编程实体框架"一书中关注了Julia Lerman关于如何拆分模型和生成的POCO类的方法.数据库模型已设置多年,并不是更改表和关系,触发器,存储过程等的选项,所以我基本上坚持使用db模型.

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

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

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

我还发现POCO类之间的关系有点过于以数据为中心.换句话说,我觉得我需要一个更简化的域模型来使用.也许我应该创建一个适合该法案的域模型,然后使用POCO类作为"DAO"来填充域模型类？

您将如何使用Repository模式和Unit of Work模式实现此目的？(如果这是要走的路)

Answer 1

警钟响了我!我们尝试过类似的事情(只有nHibernate而不是EF4).我们在运行ADO.NET和ORM时遇到了一些问题 - 数据库并发性很大.

数据库模型已设置多年,并不是更改表和关系,触发器,存储过程等的选项,所以我基本上坚持使用db模型.

是的.一样!问题是我们的存储过程包含很多业务逻辑并且不是简单的CRUD过程,所以保持ORM更新存储过程执行的各种更新根本不容易 - 单一责任原则 - 不是一个好的打破!

我的计划是随着时间的推移用EF替换旧的db访问代码,并摆脱
UI层和数据层之间的紧密耦合.

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

如果您的数据库是"王者"并且您的应用程序是高度数据驱动的,我认为您将始终在实施您提到的模式的艰难战斗.

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

Answer 2

EDMX + POCO 类生成器生成 EFv4 代码，而不是 EFv4.1 代码，但您不必担心这些细节。EFv4.1 只提供了不同的 API，其功能完全相同（并且它只是 EFv4 API 的包装器）。

根据您使用数据集的方式，您可能会遇到一些非常困难的问题。数据集是变更集模式的表示。他们知道对数据进行了哪些更改，并且能够存储这些更改。仅当 EF 实体附加到从数据库加载它们的上下文时，它们才知道这一点。一旦您使用分离的实体，您必须付出很大的努力来告诉 EF 发生了什么变化 -特别是在修改关系时（分离的实体是 Web 应用程序和 Web 服务中的常见场景）。为此，EF 提供了另一个名为“自跟踪实体”的模板，但它们还有其他问题和限制（例如缺少延迟加载、当具有相同键的实体附加到上下文时无法应用更改等）。

EF 也不支持数据集中使用的多项功能 - 例如唯一键和批量更新。有趣的是，较新的 MS API 通常可以解决以前 API 的一些难题，但同时提供的功能比以前的 API 少得多，从而引入了新的难题。

另一个问题可能与性能有关 - EF 比直接使用数据集进行数据访问要慢，并且内存消耗更高（是的，报告了一些内存泄漏）。

您可以忘记使用 EF 来访问您在设计时不知道的表。EF 不允许任何动态行为。表名和数据库服务器类型在映射中是固定的。另一个问题可能与您使用触发器的方式有关 - ORM 工具不喜欢触发器，并且 EF 在处理数据库计算值时功能有限（在数据库或应用程序中填充值的可能性是分离的）。

从 EF + 数据集填充 POCO 的方式听起来在仅使用 EF 时是不可能的。EF 有一些允许的映射模式，但将多个表映射到单个 POCO 类的可能性极其有限和受限（如果您想让这些表可编辑）。如果您的意思是仅从 EF 加载一个实体，从数据适配器加载另一个实体，并在它们之间进行引用，那么您应该没问题 - 在这种情况下，存储库听起来像是合理的模式，因为存储库的目的正是这样：加载或保留数据。工作单元也可以使用，因为您很可能希望在 EF 和数据适配器之间重用单个数据库连接，以避免在保存更改期间出现分布式事务。UoW 将是负责处理此连接的地方。

EF 映射与数据库设计相关 - 您可以引入一些面向对象的修改，但 EF 仍然紧密依赖于数据库。如果您想使用某些高级域模型，您可能需要从 EF 和数据集填充单独的域类。同样，存储库有责任隐藏这些详细信息。