Comments on: Build Your Own Data Access Layer: Hydrating Entities http://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/ inquisitive: adjective. given to inquiry, research, or asking questions; eager for knowledge; intellectually curious Wed, 08 Feb 2012 11:42:42 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Anders Ivnerhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22415 Anders Ivner Tue, 01 Sep 2009 08:51:37 +0000 http://davybrion.com/blog/?p=1524#comment-22415 Having used a similar approach myself a while ago, I ran into an issue <a href="http://andersivner.blogspot.com/2008/05/nullable-enums.html" rel="nofollow">converting integers to nullable enums</a>. It looks like it might affect your code as well.(Mine reflects "on the fly", doesn't have an identity map (as my scenario didn't require one), and is generally more of a hack than yours. Still, it worked well enough.) Having used a similar approach myself a while ago, I ran into an issue converting integers to nullable enums. It looks like it might affect your code as well.

(Mine reflects “on the fly”, doesn’t have an identity map (as my scenario didn’t require one), and is generally more of a hack than yours. Still, it worked well enough.)

]]> By: Davy Brionhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22368 Davy Brion Sat, 29 Aug 2009 10:01:05 +0000 http://davybrion.com/blog/?p=1524#comment-22368 @Michaelthe last one... i have to build the metadata model when the application starts up, and generating the datasets at that point can be a bit too expensive at that time when you have many tables. And considering the fact that the datasets don't really offer any other real benefits, i don't really see the point in doing that. @Michael

the last one… i have to build the metadata model when the application starts up, and generating the datasets at that point can be a bit too expensive at that time when you have many tables. And considering the fact that the datasets don’t really offer any other real benefits, i don’t really see the point in doing that.

]]> By: Michael Brownhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22364 Michael Brown Fri, 28 Aug 2009 18:48:53 +0000 http://davybrion.com/blog/?p=1524#comment-22364 Fair enough, just curious. I wasn't aware of an app startup performance hit. Could you provide some links to information regarding it. Or do you mean looking at the metadata and creating the dataset as a performance hit? Fair enough, just curious. I wasn’t aware of an app startup performance hit. Could you provide some links to information regarding it. Or do you mean looking at the metadata and creating the dataset as a performance hit?

]]> By: Davy Brionhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22345 Davy Brion Wed, 26 Aug 2009 21:36:02 +0000 http://davybrion.com/blog/?p=1524#comment-22345 i really dislike datasets, even the strong-typed ones... they really wouldn't save that much code actually, and the overhead of using them as well as the time increase at application startup is just not worth it IMO i really dislike datasets, even the strong-typed ones… they really wouldn’t save that much code actually, and the overhead of using them as well as the time increase at application startup is just not worth it IMO

]]> By: Michael Brownhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22344 Michael Brown Wed, 26 Aug 2009 21:15:43 +0000 http://davybrion.com/blog/?p=1524#comment-22344 I have an interesting question, why not generate strong datasets from your table info metadata and use those instead of DataReaders. I think you can turn tracking off on your datasets and they will more or less function exactly as your dictionary does currently (with slightly added overhead but dramatically reduced complexity in your code). I have an interesting question, why not generate strong datasets from your table info metadata and use those instead of DataReaders. I think you can turn tracking off on your datasets and they will more or less function exactly as your dictionary does currently (with slightly added overhead but dramatically reduced complexity in your code).

]]> By: Davy Brionhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22338 Davy Brion Wed, 26 Aug 2009 07:05:18 +0000 http://davybrion.com/blog/?p=1524#comment-22338 @Alexread the other posts... this isn't about building a full blown ORM and i don't support the inheritance hierarchies which would cause problems with lazy loading @Alex

read the other posts… this isn’t about building a full blown ORM and i don’t support the inheritance hierarchies which would cause problems with lazy loading

]]> By: Alex Yakuninhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22337 Alex Yakunin Wed, 26 Aug 2009 07:02:10 +0000 http://davybrion.com/blog/?p=1524#comment-22337 And about CreateProxy(tableInfo, referenceInfo, foreignKeyValue): you can do this only if you exactly know the type mapped to referenceInfo, or this information is contained in foreignKeyValue. If you don't know the type exactly (e.g. there is an inheritance hierarchy), you can't do this. And about CreateProxy(tableInfo, referenceInfo, foreignKeyValue): you can do this only if you exactly know the type mapped to referenceInfo, or this information is contained in foreignKeyValue. If you don’t know the type exactly (e.g. there is an inheritance hierarchy), you can’t do this.

]]> By: Alex Yakuninhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22336 Alex Yakunin Wed, 26 Aug 2009 06:56:36 +0000 http://davybrion.com/blog/?p=1524#comment-22336 AFAIK, "hydration" is frequently referenced as "materialization": http://www.google.com/search?q=ORM+materialization AFAIK, “hydration” is frequently referenced as “materialization”: http://www.google.com/search?q=ORM+materialization

]]> By: Davy Brionhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22335 Davy Brion Wed, 26 Aug 2009 06:49:44 +0000 http://davybrion.com/blog/?p=1524#comment-22335 yeah, it shortens the time needed to keep the datareaders open, and i used a dictionary instead of an array because i didn't want to deal with column positions and because it would be easy to retrieve specific values based on the column names (which i already have in the meta data model) yeah, it shortens the time needed to keep the datareaders open, and i used a dictionary instead of an array because i didn’t want to deal with column positions and because it would be easy to retrieve specific values based on the column names (which i already have in the meta data model)

]]> By: VirtualStaticVoidhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22334 VirtualStaticVoid Wed, 26 Aug 2009 06:37:38 +0000 http://davybrion.com/blog/?p=1524#comment-22334 I'm curious as to why in the HydrateEntities() method, you load up a List<IDictionary>() with data from the reader first, and then create/load each entity.My first guess is to shorten the time you have an open connection to the database. I’m curious as to why in the HydrateEntities() method, you load up a List<IDictionary>() with data from the reader first, and then create/load each entity.

My first guess is to shorten the time you have an open connection to the database.

]]> By: Jasonhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22333 Jason Wed, 26 Aug 2009 01:42:30 +0000 http://davybrion.com/blog/?p=1524#comment-22333 Ok, that makes more sense :) Ok, that makes more sense :)

]]> By: Fabio Maulohttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22331 Fabio Maulo Tue, 25 Aug 2009 22:51:47 +0000 http://davybrion.com/blog/?p=1524#comment-22331 NHibernate light NHibernate light

]]> By: New and Notable 362 : Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows)http://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22329 New and Notable 362 : Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows) Tue, 25 Aug 2009 21:49:43 +0000 http://davybrion.com/blog/?p=1524#comment-22329 [...] This is late but Davy Brion has started a series on Build Your Own Data Access Layer Series. Some posts include Out of the Box CRUD Functionality, Mapping Classes to Tables, and Hydrating Entities. [...] [...] This is late but Davy Brion has started a series on Build Your Own Data Access Layer Series. Some posts include Out of the Box CRUD Functionality, Mapping Classes to Tables, and Hydrating Entities. [...]

]]> By: Davy Brionhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22327 Davy Brion Tue, 25 Aug 2009 21:14:01 +0000 http://davybrion.com/blog/?p=1524#comment-22327 @Jasonin the previous post (http://davybrion.com/blog/2009/08/build-your-own-data-access-layer-out-of-the-box-crud-functionality/) i mentioned the following about the GetByIdAction:"This will first check the session level cache to see if this instance has already been retrieved in the current session (i’ll discuss the session in a later post) and if so, it will return that instance. If it’s not in the cache, it will create a SqlCommand and fill its CommandText property with a SQL string that is provided by the relevant TableInfo class. After that, it passes the SqlCommand to the EntityHydrater so it can return an actual entity instance."As for checking the cache after the records have been retrieved, that is explained in the next post, which will be published tomorrow ;) @Jason

in the previous post (http://davybrion.com/blog/2009/08/build-your-own-data-access-layer-out-of-the-box-crud-functionality/) i mentioned the following about the GetByIdAction:

“This will first check the session level cache to see if this instance has already been retrieved in the current session (i’ll discuss the session in a later post) and if so, it will return that instance. If it’s not in the cache, it will create a SqlCommand and fill its CommandText property with a SQL string that is provided by the relevant TableInfo class. After that, it passes the SqlCommand to the EntityHydrater so it can return an actual entity instance.”

As for checking the cache after the records have been retrieved, that is explained in the next post, which will be published tomorrow ;)

]]> By: Jasonhttp://davybrion.com/blog/2009/08/build-your-own-data-access-layer-hydrating-entities/comment-page-1/#comment-22326 Jason Tue, 25 Aug 2009 20:54:20 +0000 http://davybrion.com/blog/?p=1524#comment-22326 what value does session level cache provide is this scenario? you are not checking the cache until after the record is loaded from the database, so you're not gaining preformance be decreasing trips to the database. Would you want to check the session cache before constructing/executing the sql statement to reduce trips to the database? what value does session level cache provide is this scenario? you are not checking the cache until after the record is loaded from the database, so you’re not gaining preformance be decreasing trips to the database. Would you want to check the session cache before constructing/executing the sql statement to reduce trips to the database?

]]>