Foundations of Programming - Karl Seguin

Chapter 6 - Object Relational Mappers
Object Relational Mappers
THE OTHER OPTION INVOLVED WRITING WAY TOO MUCH SQL. - CHRIS KOCH
I
n chapter 3 we took our first stab at bridging the data and object world by hand-writing our own
data access layer and mapper. The approach turned out to be rather limited and required quite a bit
of repetitive code (although it was useful in demonstrating the basics). Adding more objects and
more functionality would bloat our DAL into an enormously unmaintainable violation of DRY (don’t
repeat yourself). In this chapter we’ll look at an actual O/R Mapping framework to do all the heavy lifting
for us. Specifically, we’ll look at the popular open-source NHibernate framework.
The single greatest barrier preventing people from adopting domain driven design is the issue of
persistence. My own adoption of O/R mappers came with great trepidation and doubt. You’ll essentially
be asked to trade in your knowledge of a tried and true method for something that seems a little too
magical. A leap of faith may be required.
The first thing to come to terms with is that O/R mappers generate your SQL for you. I know, it sounds
like it’s going to be slow, insecure and inflexible, especially since you probably figured that it’ll have to
use inline SQL. But if you can push those fears out of your mind for a second, you have to admit that it
could save you a lot of time and result in a lot less bugs. Remember, we want to focus on building
behavior, not worry about plumbing (and if it makes you feel any better, a good O/R mapper will provide
simple ways for you to circumvent the automated code generation and execute your own SQL or stored
procedures).
Infamous Inline SQL vs. Stored Procedure Debate
Over the years, there’s been some debate between inline SQL and stored procedures. This debate has
been very poorly worded, because when people hear inline SQL, they think of badly written code like:
string sql = @"SELECT UserId FROM Users
WHERE UserName = '" + userName + "'
AND Password = '" + password + "'";
using (SqlCommand command = new SqlCommand(sql))
{
return 0; //todo
}
Of course, phrased this way, inline SQL really does suck. However, if you stop and think about it and
actually compare apples to apples, the truth is that neither is particularly better than the other. Let's
examine some common points of contention.
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
43
6