2

Szenario:

I have read the book P of EAA by Martin Fowler and stumbled over the pattern called Identity Map. I've thought about using this pattern in an ASP.NET MVC application.

Question:

As far as I know the ASP.NET MVC request life-cycle always kills all objects after a request got processed, which means my domain layer / mapping layer (containing my Identity Map) would be cleared as well. How can I use this pattern (see below) in a stateless environment like ASP.NET MVC? Does it make sense in a stateless environment? Could I make the Identity Map static and introduce a session id to regain my objects I have already loaded?

Identity Map:

Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them. Martin Fowler

enter image description here

MUG4N
  • 19,377
  • 11
  • 56
  • 83
  • [Read this](http://stackoverflow.com/questions/12554213/). regarding your question, a limited usage can be made, but using the same context for several request can give you stale data. – gdoron Jul 11 '13 at 17:43

1 Answers1

1

Identity maps are used to implement the first level cache in many Object-Oriented Mappers. If your application stack involves Entity Framework or nHibernate (or yet another orm) most probably you already have an identity map there. But this is what you probably know already.

The question whether or not an identity map could be static doesn't have a definite answer and I could probably imagine a situation where it could work but drawbacks are severe:

  • the cache would not be able to easily see any external changes
  • the memory consumption would grow without control
  • concurrency issues could occur

Implementation of an identity map which would be free of all these issues would probably be unnecessary difficult. It is just safer and less expensive to restrict the map's lifetime to a single request. Note that it still does its job - if a request involves multiple reads, the identity map serves the data rather than the database when applicable.

Wiktor Zychla
  • 47,367
  • 6
  • 74
  • 106