问题标签 [identity-map]

OK, I read these:

EntityFramework show entities before saving changes

Where added objects are stored in ObjectContext?

I guess there is no clear solution of the problem (although the second post is from 2009) but I think it's an important issue of Entity Framework so I will ask my question despite all.

Let say we have code like that:

If we use NHibernate, the UnitOfWork implementation will encapsulate an ISession instance. And the given code will behave as we expect - we can get newly added category back from the repository (i.e. underlying ISession) before changes are committed.

I was surprised to discover that Entity Framework behave different. If our UnitOfWork implementation encapsulate EF's ObjectContext, the assertion fails. Before calling ObjectContext.SaveChages() (in the unitOfWork.Commit() method), newly added category is not reachable (via the same ObjectContext). I tried to find some property of ObjectContext that configure this behavior but didn't succeed.

So my question is: Is it possible to get entities from ObjectContext we just added without need of calling ObjectContext.SaveChages() (because we don't want to commit until the business transaction ends)? If the answer is "No", is not this violation of the Identity Map design pattern in particular and the UnitOfWork pattern in general? And if you use EF how deal with this scenarios?

Thanks in advance.

Sorry for the delay, guys.

It seems that you don't get my point. The question is not "How to get back this instance I've just added?" After all I have a reference to it. The question is "How does any newly added (still uncommitted - and actually it is possible never to be committed) entity to be considered by any query over the given DbSet?"

If I add a new category and then write something like that (I'm intentionally not using repository here but row DbContext (or ObjectContext if we are using EF 4.0) to be clearer to you):

I want my new category to be returned in the result set if it satisfied the condition. Probably this query will be executed in another method (or even another class) that just share the same context (repository) within single transaction (unit of work). I know I can execute the same query over the Categories.Local, filter the result only to newly added entities (since Local contains all entities of the set that are currently being tracked) and combine it with result returned from the database. Don't you think it's terribly ugly? And I'm not even sure if I'm not missing something right now. All this is work of the ORM. It's all about transactional behavior (unit of work) and the ORM should handle it (like NHibernate does).

Now does it make sense to you?

一个用户故事：

我们应用程序的用户创建了公路旅行。Aroadtrip是一系列有趣的目的地。每个destination人都有一些关于在那里看到的活动或景点的细节。通过这种方式，我们的用户定义了两次公路旅行，其中每次旅行都有一些独特的目的地和一些共同的目的地——例如，两次旅行都包括史密森尼博物馆。该应用程序在内存中维护所有更新，并且仅在用户单击保存时才提交到数据库。用户主动更新两个行程，可以随意切换。在我们的应用程序中，我们正在处理史密森尼目的地，但有时我们需要向上导航我们的对象层次结构，从目的地到其包含的公路旅行。问题是目的地参加了两次公路旅行。

我们可以使用什么好的设计模式或数据结构来允许向后导航，同时确保我们只有一个目标对象的副本？

要求：

1. 您的模型涉及多对多关系。
2. 在内存中仅表示所有模型一次（身份映射）。
3. 您的数据结构应该易于导航。您不仅可以从父级导航到子级，还可以从子级导航回到最初获取子级的父级。
4. 我想避免向数据模型引入额外的模式。

到目前为止，我最好的想法是用上下文对象包装每个目标对象（类似于链表包装节点的方式）。上下文对象将维护一个指向最初从中获取它的父对象的指针。我们将始终通过其包装器处理每个目的地。我相信这将是代理模式或装饰器模式（我倾向于代理）。（这与 jQuery 对象包含许多元素并且多个 jQuery 对象共享对相同元素的引用的方式本质上不是相同的想法吗？）

我考虑维护一个“当前公路旅行”上下文变量，并将其用于从目的地导航到其包含的公路旅行。这不如实际的“获取上下文”可靠。事实上，这是一种完全不同的策略，我不确定我是否喜欢它。

我记得 ActiveRecord 也有同样的问题（尽管我已经有一段时间没有使用它了）。在 AR 中，如果我从 RoadTrip1 开始，然后获取它的目的地，我就不能很好地从目的地导航到公路旅行（通过某种获取上下文）。相反，我会考虑父母双方（公路旅行），并且没有迹象表明我是如何到达那里的。对？

其他人之前是否遇到过这个问题 - 也就是说，想要向后导航，而向后导航被许多父母混淆了？你有没有问过“我是从哪个家长那里来的？” 你是怎么回答的？

我有一个控制器，它基本上获取一条记录并实例化为一个对象。
当它运行时，该对象会使用不同的 object_id 实例化两次。

例如

这会在运行 rails 的终端上打印两个不同的 id（仅在 rails 3.1 中）。在 Rails 3 中，它只有一个 id。它还将两个不同的用户对象实例化为对数据库或资源的两个查询。

我没有任何线索。我什至不知道用谷歌搜索什么。我看到了一些东西，ActiveRecord::IdentityMaps但我不明白这里有什么问题。

在 Martin Fowler 的“企业应用程序架构模式”中，描述了用于组织 DAL 的方法，例如一组实体映射器。每个都有自己的 IdentityMap 存储特定实体。

例如在我的 ASP.NET WebApplication 中：

}

问题是：在哪里存储这些映射器？系统服务（实体）应该如何调用映射器？

我决定创建包含所有映射器的 MapperRegistry。因此服务可以调用映射器，例如：

但是我可以在哪里存储 MapperRegistry 实例？我看到以下变体，但不喜欢其中任何一个：

1. MapperRegistry 是全局应用程序（单例）

   • 不适用，因为在多线程 ASP.NET 应用程序中需要同步（至少 Martin 说只有 mad 可以选择此变体）

2. 每个会话的 MapperRegistry

   • 好像也不太好。所有 ORM（NHibernate、LINQ to SQL、EntityFramework）大师都建议对每个请求使用 DataContext（NHibernateSession、ObjectContext），而不是在 Session 中存储上下文。
   • 同样在我的 WebApp 中，几乎所有请求都是对 EntityController.asmx（具有属性 ScriptService）返回 JSON 的 AJAX 请求。并且不允许会话。

3. 每个请求的 MapperRegistry

   • 有很多单独的 AJAX 调用。在这种情况下 MapperRegistry 的生命周期将太小。因此，数据几乎总是会从数据库中检索出来，因此性能低下。

亲爱的专家，请帮助我解决架构问题。

我们的代码中有一个场景，即只允许更改实体的少数属性。为了保证这一点，我们有类似这样的代码：

这段代码的问题是调用dbContext.GetCustomerById并不总是给我一个新的Customer类实例。如果客户已经从数据库中获取，Entity Framework 会将实例保存在内存中，并在每次后续调用时返回它。

这将我们引向实际问题——customer并且originalCustomer可能指的是同一个实例。在这种情况下，customer.Name将等于originalCustomer.Name，我们将无法检测它是否与数据库不同。

我猜大多数其他 ORM 也存在同样的问题，因为 identitymap 设计模式。

有什么想法可以解决这个问题吗？我可以以某种方式强制 EF 始终为我提供客户类的新实例吗？

还是我们应该重构代码？有谁知道这种场景有什么好的设计模式？

据我所知，实体框架实现了身份映射模式，因此 EF 在内存中缓存了一些实体。

让我给你举个例子。

有没有办法在student不重新创建上下文的情况下使第一个上下文的缓存无效并检索新实体？

感谢帮助。

Mongoid 2.4.4 Rails 3.2.1 MongoDB 2.0.1

我有 3 个模型：

认证、收藏和内容。</p>

它就像从身份验证到内容到收藏夹的多对多关系。

当我这样查询时：

@favorites = Favorite.any_in(authentication_id: list).includes(:content, :authentication).desc(:collected_at).page params[:page]

@favorites 工作正常

@favorites 的内容也可以正常工作。

但是@favorites 的身份验证只有_id，所有其他字段都为零

当我设置 identity_map_enabled: false 时，它​​已修复。

这是 identity_map 的错误吗？

这是tracert的一些信息，
当启用身份映射时，您可以看到 f.weibo.name 为 nil。

当 identity_map_enabled: true 时如何解决这个问题？

- - - - - - - - - - - 楷模 - - - - - - - - - - - - - - -----

-------------- 调试代码：------------

--------- 调试代码结束 ---------

--------- LOG identity_map_enabled: true --------

--------- LOG identity_map_enabled: false --------------------

我已经编写了如下测试代码：

我预计 dbset 将返回添加的实体。但它只有在将更改保存到真实数据库后才给我对象。

我正在我的项目中实现身份映射模式和 DataMapper 模式。但我有一些问题。

当我通过网关从数据库中获取数据时，我正在创建对象的新实例并返回 List ...

关于身份映射，从数据库获取数据的最佳方法是什么？我想从数据库中获取患者并将这些数据显示给用户..

身份图中对象的 ID 呢？我的解决方案（在我看来）：1）使用一些默认 id 创建新对象 2）将对象保存到数据库 3）获取数据库中最后一个对象的 id 4）设置对象的新 id 5）使用新 id 保存到缓存... .

这是一个很好的解决方案？

谢谢你的帮助！

我的身份映射对象（单例）：

还有Pacient Mapper：

塞纳里奥：

我读过 Martin Fowler 的书P of EAA，偶然发现了名为 Identity Map 的模式。我考虑过在 ASP.NET MVC 应用程序中使用这种模式。

问题：

据我所知，ASP.NET MVC 请求生命周期总是在处理请求后杀死所有对象，这意味着我的域层/映射层（包含我的身份映射）也将被清除。如何在像 ASP.NET MVC 这样的无状态环境中使用这种模式（见下文）？在无状态环境中有意义吗？我可以将身份映射设为静态并引入会话 ID 以重新获得我已经加载的对象吗？

身份图：

通过将每个加载的对象保存在地图中，确保每个对象仅加载一次。在引用对象时使用地图查找对象。马丁·福勒