Comments on: Build Your Own Data Access Layer: Session Level Cache http://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/ inquisitive: adjective. given to inquiry, research, or asking questions; eager for knowledge; intellectually curious Sun, 20 May 2012 21:55:00 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Davy Brionhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22380 Davy Brion Sun, 30 Aug 2009 12:18:24 +0000 http://davybrion.com/blog/?p=1526#comment-22380 @RaoulThere is only one reason, and that is that i didn't want entity classes to have to implement an interface or inherit from a base class to be able to use a strongly typed Id property. I use reflection to get or set properties, and when getting a value it is always retrieved as object. I just thought it would be easier to continue using object for identifier values instead of casting it to an int/long every time i retrieved it. @Raoul

There is only one reason, and that is that i didn’t want entity classes to have to implement an interface or inherit from a base class to be able to use a strongly typed Id property. I use reflection to get or set properties, and when getting a value it is always retrieved as object. I just thought it would be easier to continue using object for identifier values instead of casting it to an int/long every time i retrieved it.

]]> By: Raoul Millaishttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22379 Raoul Millais Sun, 30 Aug 2009 11:00:35 +0000 http://davybrion.com/blog/?p=1526#comment-22379 Firstly, thank you for an incredibly interesting blog post series. Given that you stated in the limitations that your ORM would only work with SQL Server IDENTITY generated primary keys, I was wondering what the rationale behind loosely typing the id everywhere as an object rather than using int/long. Is this to ease implementing alternative primary key strategies in the future? If so, surely you would need to make widespread changes to facilitate this anyway and YAGNI? Firstly, thank you for an incredibly interesting blog post series. Given that you stated in the limitations that your ORM would only work with SQL Server IDENTITY generated primary keys, I was wondering what the rationale behind loosely typing the id everywhere as an object rather than using int/long. Is this to ease implementing alternative primary key strategies in the future? If so, surely you would need to make widespread changes to facilitate this anyway and YAGNI?

]]> By: Reflective Perspective - Chris Alcock » The Morning Brew #421http://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22350 Reflective Perspective - Chris Alcock » The Morning Brew #421 Thu, 27 Aug 2009 07:36:00 +0000 http://davybrion.com/blog/?p=1526#comment-22350 [...] Build Your Own Data Access Layer: Session Level Cache - Davy Brion presses on with his series on building your own DAL / ORM with a look at session level caching using the identity map pattern [...] [...] Build Your Own Data Access Layer: Session Level Cache – Davy Brion presses on with his series on building your own DAL / ORM with a look at session level caching using the identity map pattern [...]

]]> By: Davy Brionhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22349 Davy Brion Thu, 27 Aug 2009 05:05:28 +0000 http://davybrion.com/blog/?p=1526#comment-22349 @Joshwhat exactly do you mean with flushing the cache? If you mean flushing changes made to cached objects to the database, then no... that won't be in ityou do have the ability to clear the cache entirely or parts of it thoughbut keep in mind that this is a _Session_ level cache... sessions are supposed to be pretty short-lived so the SessionLevelCache shouldn't even get the chance to become a memory issue. @Josh

what exactly do you mean with flushing the cache? If you mean flushing changes made to cached objects to the database, then no… that won’t be in it

you do have the ability to clear the cache entirely or parts of it though

but keep in mind that this is a _Session_ level cache… sessions are supposed to be pretty short-lived so the SessionLevelCache shouldn’t even get the chance to become a memory issue.

]]> By: flukushttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22348 flukus Thu, 27 Aug 2009 04:26:36 +0000 http://davybrion.com/blog/?p=1526#comment-22348 Having written an ORM for my current company I have to say that not having a session cache was the biggest mistake I made. Realizing that your dealing with object graphs instead of relational tables was one of those 'Eureka' moments. Unfortuneatly it came to late.The other big mistake was not having lazy loading. Our initial requirements didn't really need it so that was more of an omission than a mistake. Having written an ORM for my current company I have to say that not having a session cache was the biggest mistake I made. Realizing that your dealing with object graphs instead of relational tables was one of those ‘Eureka’ moments. Unfortuneatly it came to late.

The other big mistake was not having lazy loading. Our initial requirements didn’t really need it so that was more of an omission than a mistake.

]]> By: New and Notable 363 : Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows)http://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22347 New and Notable 363 : Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows) Wed, 26 Aug 2009 23:36:08 +0000 http://davybrion.com/blog/?p=1526#comment-22347 [...] Build Your Own Data Access Layer: Session Level Cache [...] [...] Build Your Own Data Access Layer: Session Level Cache [...]

]]> By: Joshhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22346 Josh Wed, 26 Aug 2009 22:19:11 +0000 http://davybrion.com/blog/?p=1526#comment-22346 Love this series - very insightful.I was wondering if you were going to put in any means to flush the cache? Couldn't memory become an issue if you don't? Love this series – very insightful.

I was wondering if you were going to put in any means to flush the cache? Couldn’t memory become an issue if you don’t?

]]> By: Davy Brionhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22343 Davy Brion Wed, 26 Aug 2009 20:53:21 +0000 http://davybrion.com/blog/?p=1526#comment-22343 nope, sorry... i'm allowed to blog about it but i can't release the code in a downloadable form nope, sorry… i’m allowed to blog about it but i can’t release the code in a downloadable form

]]> By: VirtualStaticVoidhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22342 VirtualStaticVoid Wed, 26 Aug 2009 18:03:25 +0000 http://davybrion.com/blog/?p=1526#comment-22342 It's particularly interesting following your series as well as <a href="http://ayende.com/Blog/archive/2009/08/26/a-guide-into-orm-implementation-challenges-hydrating-entities.aspx" rel="nofollow">Ayende's</a> "shadow" posts, which combined seem to provide a good high-level of the internals of NHibernate.Do you plan to provide the source code as a download at the end of the series? It’s particularly interesting following your series as well as Ayende’s “shadow” posts, which combined seem to provide a good high-level of the internals of NHibernate.

Do you plan to provide the source code as a download at the end of the series?

]]> By: Kris-Ihttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-session-level-cache/comment-page-1/#comment-22341 Kris-I Wed, 26 Aug 2009 16:18:56 +0000 http://davybrion.com/blog/?p=1526#comment-22341 Don't forget to prepare your VISUG presentation :) Don’t forget to prepare your VISUG presentation :)

]]>