On Leaky Abstractions and a developer sanity.
Paul
Graham has an article about Great
Hackers that is worth reading. (I listened to the podcast, and
it's much better when you can hear him speaks than just read the text). Joel has a very good article about Leaky
Abstractions (although no podcast about that).
Put those things together, and you
can get a fairly good idea about why leaky abstractions are so annoying
for developers. If you read my blog you're aware of much hair pulling and gnashing
of teeth in regards to ASP.Net that has been going on lately. Most of the
problem is that I don't really understand what is going on under the hood. On
the other side, I've had a similar experience with NHibernate and ActiveRecord.
I had a page that had to display a
list of records from the database. Currently the database holds ~5 rows. The
page loaded very quickly, but I took a look at the profiler to see what kind of
SQL statements were executed and I nearly had a scream fit about it*. 18 statements
for loading 5 rows? All of them in the same table? I got into a short argument
(with myself, this time) about the usefulness of an ORM that generate such
lousy code. I then put a couple of dozens of Lazy = true in various places in
my code, and watch the page load again. There was only one SQL statement this
time, and while it wouldn't pass the code police (horrible names), it
did the work. For a moment, though, I had a very real sense of what would've
happened if another developer, who isn't familiar with NHibernate or
ActiveRecord would have with the same problem.
The second issue that I had was a
matter of cascading. I thought that I had information, because I created it and
then saved the root object to the database. But when I tried to get the
information, I couldn't find it. The issue is (probably) that I didn't
configure the cascades properly. I think that I fixed this by adding the proper
cascade (I'm writing this post in the breaks that I have to take because of the
long compile times for ASP.Net). Adding cascades broke the tests, which
require some fixing, but it was very straightforward, most of the time.
Okay, I usually try to have a point
with my posts, so let's try to give this one at least moderate one. The issue
here is about control; understanding and how leaky is the abstraction. NHibernate
is great, and I think that I cut in more than half the time that
I need to spend thinking about data access. In fact, it's so good that I don't
think about it most of the time.
Implementing the Session-Pre-Request
and Session-Per-Test is very straightforward using ActiveRecord, and it is a
joy to work with. I had written some very bad application in the past (and I'm
sure that I'll say it again in the futureJ),
and I distinctly remember the amount of thought that I had to dedicate to building
any non-trivial queries. Keeping an eye on what is going on under the covers is
good, but it is so good not having it in your face all the time.
* One SQL statement was so
horrendous it was 5KB(!!) and had 11 joins! I couldn't follow it, and I was too
afraid to see what the execution plan looked like.
Comments
Comment preview