DNR, generics, and O/R mapping
I recently discovered the radio shows over at DotNetRocks hosted by Carl
Franklin. These shows are pretty good, I love that
you can download the full mp3 show, I'm downloading all of them and I put them
on my Dell DJ and listen to them in the car; it
makes the drive to work much more appealing.
I'm in the middle of the show with Mark Pollack, Ted
Neward, and Don
Box, which is especially interesting because these
guys are not afraid to push each other's buttons. They talked about
generics in java, and how Sun just put it into jdk 1.5 because of
all the hype that C# was getting for putting generics into Whidbey. While
java supports generics now, you don't get the total benefits of generics like
you do in C# because all the java compiler does is convert all the generic types
into objects, so you still have the performance overhead of the boxing
operations, whereas in C# if you define a List<string>, it really is a
List of strings.
The part of the conversation that I'm at right now is where
they are all discussing object relational mapping, and the problems with current
attempts to transpose relational data into language objects. This topic is
particularly interesting to me, because we use some custom o/r mapping objects
at work, in C#.
They used a Person object as an example, so suppose you have
a person table in your database, and a corresponding Person class in your
application. When you are accessing the Person instance, you would supply
the primary key, say 1, of the person that you want to access. So your
application needs to go to the database and retrieve the fields of the person
table, and populate your Person instance. The problem is what fields
should the application retrieve? Do you grab all the fields, even if you
just want that person's email address? Thats a waste of database overhead.
But you cannot just load every field on demand because the situation will arise
where you need all or most of the fields, and its silly to query the database
separately for each field. So what to do? In our implementation at
work, I load all the fields at once. I find the performance is not an
issue, even for the case of one table that has > 100 fields. So IMO,
loading all at once is not a problem. But Carl made a suggestion that I
thought was really clever. He suggested using custom attributes to specify
which fields are loaded by default, and which fields are "lazy loaded." So for
our Person class, maybe FirstName, LastName, Email, and Address are always
loaded, and then Phone, Company, Fax, City, State, Zip, Country are only loaded
when we explicitly access those fields. This scheme would work very well
with that table I mentioned with many fields, and I think the benefits would
certainly be seen if you had a table that was storing blobs, so you could load
all the fields besides the blob, and just grab the blob when you actually needed
the binary data.
This show is compelling so far, I'm looking forward to the
rest of it on my way to work Monday.