This is the next post on my series on ORMs.
On a related note to the last post on [[Object Relational Mappers Series - Concurrency and the Non-Updating Update|concurrency]] is caching. Most ORMs use caching as a selling point, and I believe it is valid...to a point. The ORM will cache an entity graph and then manage that cache for the developer. If you have a simple application then this is a huge benefit. But the ORM vendor usually doesn't give you fine-grained control over the cache, such as when to flush the cache, mark it dirty, etc. The ORM wants to handle that for you. But what if the underlying data source is used by more "applications" than just the application the ORM is aware of. ORM caches just aren't smart enough to handle those cases. Again, with optimistic concurrency you can see where you have the potential for conflicts.
ORM vendors point to the fact that the caching abilities, albeit rudimentary, allow your application to run in a disconnected state. I agree with that statement...it does help with that...but I really don't need an ORM to allow my application to run in a disconnected state. If I want a caching solution I likely want something more robust. Will the ORM support a universal cache on a business rules tier or only at the client? If not I again risk stale data until the entity is re-fetched to all caches. Seems like I need a more robust caching solution.
Back to stored procedures for a minute...here's another reason why most ORMs will steer you clear of them...there is no way to search the cache when using a pass through query or stored procedure. They don't know what business logic is being implemented outside of the ORM.
When concurrency and cache collision issues begin to surface in your app the ORM vendor will offer a quick fix...disable the cache or manipulate it in some other way.
data architecture orm