When writing the back-end for Positive Lookahead, I chose the Enterprise Library naïvely thinking it would free me from some of the boring manual writing of data access code. The experience was quite sour because I had to wrestle too much with the damn Data Access Block and ended up writing even more code than I would’ve written with plain vanilla ADO.NET.
I’ve always hated EntLib with passion because of its viral nature. You drag one “block” in and a whole bunch of others follow. Before you know it, almost all of its DLLs are sitting in your bin folder. And don’t even get me started on the Composite UI
Application Block—that’s one ugly monster. I usually make it a point to avoid touching EntLib, but I got suckered this time.
I’ve been fiddling with NHibernate for the past two weeks, going through the docs
(PDF), poking around Ben Scheirman’s series of posts on Domain Driven Design with NHibernate (watch also this
screencast) and so on. NHibernate has a steep learning curve, but once you get the hang of it, it absolutely rocks!
No tool is perfect, and HNibernate has its fair share of flaws. Lack of decent tooling is one. I only found MyGeneration (calling it
“decent” is a stretch perhaps I spoke too soon) and CodeSmith templates (I haven’t tried them). In retrospect, I see this lack of tooling as a good thing as it keeps the RAD crowd at
bay.
Why not ActiveRecord?
Being a proponent of Domain Driven Design, I don’t like mixing persistence logic into my domain. Therefore I’m no big fan of CSLA, ActiveRecord, or SubSonic.
NHibernate allows me to keep the two separate, even though mapping them via XML files is extra (manual) work. You can’t have your cake and eat it too.
For a pet project with a simple Customer–Order–OrderDetails schema I’d use ActiveRecord, but I don’t see myself using it in complex projects.
Why not LINQ to SQL?
A friend of mine refers to LINQ to SQL as “methadone for the Access crowd” (the friend shall remain nameless because I didn’t ask a permission to quote him). I tend to agree. What’s the first thing you see in demos? Grab tables, drag ’em on the designer and—boom!—you have a “domain model.” Riiiight.
Maybe we’ll make some constructive progress in how web apps are built with .NET once people understand that their database schema is not their domain model. Relational model is simply not fit to adequately model real-life concepts and processes. That’s what an Object-Relational Mapper, like NHibernate, is for. We’ll see if LINQ to Entities gets it right.
