0

作为代码现代化计划的一部分，我试图找出一种方法来使用实体框架来增强（并最终替换）我们自己开发的 ORM。ORM 本身比上一步的直接 SQL 调用迈出了一大步，但现在其余的基础设施已经启动，我想开始逐步淘汰它。

为此，我试图弄清楚如何通过实体框架构建类，以便它们的行为类似于当前 ORM 的行为方式。理想情况下，在重新设计类时不需要任何代码更改，并且我们将获得诸如延迟加载和易于生成/更新类以匹配数据库的特性。

当前的 ORM 实际上是用于构建 SQL 语句的非常精美的包装器。 Part p = new Part(12345);将执行select * from parts where partID = 12345，然后取回它返回的 DataRow 并使用反射来填充对象上的字段。当它保存时，它做的事情几乎相同 - 它获取所有字段并使用它来更新数据行，然后将其写回数据库。通常，当我们期望它被编辑时，它也会锁定数据库中的行。有点笨拙，但它有效。

我试图找出一种方法来使用实体框架和模板以不需要持久数据上下文的方式自动生成我们的类。当前方法允许我们在需要的地方创建对象，根据需要传递它们，并且知道当它们更新时，数据库将更新以匹配该对象。我看过很多东西（根据标题），但我不知道我们可以使用哪种方法，以便在对象库之外不需要上下文。

有人可以指出我正确的方向吗？

编辑： 我可能要求太多，或者试图将一个方形钉子挤进一个圆孔。让我通过将其精简到最低限度来简化我正在寻找的内容。

有什么方法可以构造它，这样我就可以拥有一个在 a 之外有效的 CRUD 类型的对象using (var context = new Context()) {}，以便我可以将它传递给不相关的代码？我不在乎是否需要将它放回上下文中以加载/保存它，只要它在它之外工作。

如果使用 EF 无法做到这一点，那么该场景的正确设计模式是什么：一个表单打开另一个表单并传入一个 Invoice。第二种形式采用该 Invoice，引导用户为其输入付款，并生成一个新的 Payment 对象。第一种形式采用该 Payment 对象并基于它对 Invoice 进行进一步处理。然后，一切都立即提交到数据库。

4

3 回答 3

0

POCO、带有代理的 POCO 或 STE 都不符合您的架构。所有这些实体类型的重点是使您的实体持久性无知，但您的实体实现持久性。最接近您的模型的是旧数据集。

EF 的中心点是上下文。如果你想保留你的架构，每个实体都必须处理自己的上下文。那是 EF 反模式。EF 希望您有上下文并使用上下文来获取和持久化实体 - 大多数 EF 功能都依赖于这种模式。

于 2012-06-08T07:56:39.463 回答
0

如果您使用 POCO 并关闭上下文的代理生成（或者如果您在处理上下文之前分离它们），那么您的实体将在 using context 子句之外有效。

如果您的对象具有需要在 using 上下文子句之外有效的集合属性，则需要在查询中使用 include 或在离开 using 上下文子句之前填充其他查询。

于 2012-06-08T19:46:04.917 回答
0

如果您真的想使用 EF 进行延迟加载，那么您当然需要创建 EF DbContext/Object Context。我想通过删除不相关的代码（例如持久性逻辑）将您当前的类转换为 POCO 类并不是什么大不了的事。我鼓励您通过一个服务层来抽象您的持久层，该服务层执行操作 EF 上下文的工作，例如，您的表单调用服务层，服务层创建上下文实例并持久化/检索数据。

于 2012-06-08T14:31:52.257 回答