【问题标题】:Use of Self-Tracking Entities in ASP.NET across multiple Posts在多个帖子中使用 ASP.NET 中的自我跟踪实体
【发布时间】:2011-05-25 04:37:59
【问题描述】:

我有一个简单的要求(所以我想...!)

我有一个由 Order、OrderLine、Product 组成的模型。

我想创建一个订单并添加 OrderLines(每个 OrderLine 都与一个产品相关)。我创建 Order 并向其添加新的 OrderLines。在帖子之间,我将 Order 实体存储在 Session(或 ViewState)中。只是为了让你知道我已经添加了对二进制序列化的支持,效果很好。

因此关系是 Order > OrderLine(s) > Product。

您可能已经猜到问题出在哪里 - 当我 SaveChanges() 时,我得到通常的“AcceptChanges 无法继续,因为对象的键值与 ObjectStateManager 中的另一个对象冲突。”错误。

我在网上参考了许多文章,但似乎没有一篇文章处理这种情况(我有两个以上实体的关系),例如http://blogs.msdn.com/b/diego/archive/2010/10/06/self-tracking-entities-applychanges-and-duplicate-entities.aspx.

这肯定是一个非常普遍的要求吧?有没有人用实体框架做同样的事情(并且不使用 DTO 等)?

干杯 - 帮助! :)

尼克

【问题讨论】:

  • “跨多个帖子”是什么意思?这是一个网络应用程序吗?如果是这样,您不需要自我跟踪实体,也不应将其存储在会话中。您应该尊重网络的无状态特性。 STE 适用于多层应用程序(例如 WCF -> Silverlight)
  • 谢谢。是的,这是一个 Web 应用程序,我的意思是跨页面请求。我想使用 EF 生成的 Order 实体来构建订单(添加订单行、注释等)。为什么我不应该?我应该怎么做 - 通过创建我自己的“订单”实体(类),使用它,然后在保存时复制到新的 EF 订单实体?考虑到我有一个了解关联等的现成课程,这似乎需要做很多额外的工作。在这种情况下你会建议什么? (我明白使用 STE 可能不合适)

标签: asp.net entity-framework entity-framework-4 self-tracking-entities


【解决方案1】:

这就是我决定要做的……

使用 EF 生成的实体和关联(不是 STE - 你是正确的 Nick)来构建订单。始终包含外键。

将 MergeOption 设置为 NO TRACKING 即分离。

在用户构建订单时,在帖子/页面请求之间将相关实体保存在 SESSION 中。

重要提示:关联子实体(例如 OrderLines)时,不要通过关系关联现有子实体,而是使用 FK Id。所以不要使用 OrderLine.Product = product,而是使用 OrderLine.Product_Id = product.Id。这解决了存在来自不同上下文的多个实体的问题。

当订单完成并准备好保存时,添加到上下文和 SaveChanges。

--

编辑现有订单时...

将 MergeOption 设置为 NO TRACKING。

在用户编辑订单时,在帖子/页面请求之间将相关实体保存在 SESSION 中。

我使用自己的实体状态指示器,以便我可以记录分离时是否添加、修改或删除实体。

当编辑完成并准备保存时,附加到上下文,处理更改(将 ObjectState 设置为 MODIFIED 等)和 SaveChanges。

--

实现梦想 - 短暂的上下文 (UOW) - 没有视图模型或 DTO(只需使用实体类)- 没有复杂的代码(分离/附加图表等)。

注意:不存储在 VIEWSTATE 中。需要研究一下,因为我想从 InProc 更改为 SQL。会更新。

也许我错过了一些东西,但我花了很多时间研究可能的解决方案。

【讨论】:

  • 误报。可以存储在 ViewState 中 OK(需要使用 .Include 在编辑之前检索订单并存储在 ViewState 中时)。
【解决方案2】:

我经常听到“不是 STE”,但为什么不呢?我有一个包含 WinForms、WPF 和 ASP.Net 组件的多层应用程序,并且我的 STE 用于所有层。在 ASP 中,只需确保您在帖子/更改之间适当地将您的 STE 持久化回 Viewstate\Sessionstate,您的代码应该可以正常工作。

我的实体具有多个级别的关系而没有问题,这方面的例子很少,因为无论多少级,主体都是相同的。 如果您有时间/耐心让您的脚本满足您的需求,我建议您坚持使用 STE。我现在拥有一个基于我在所有应用程序中使用的 STE 的可靠框架。

当模型和管理应用程序实际上是 .Net 4.0 时,STE 允许我访问 SharePoint (.Net 3.5) 中的数据,这是 STE 与实体框架相比经常被忽视的好处之一。

请参阅Self-Tracking Entities: ApplyChanges and duplicate entities 以获取有关您特定问题的帮助。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多