Matt Hinze @ FWDNUG

I saw a post today about ORMs and how they are hard to use and maintain.  Since we saw ActiveRecord/NHibernate at Ben's talk and we're going to have more talks on ORM tools there may be questions.  I wanted to share my experience and assuage some fears about ORMs that may be holding you up from getting started..

I'm using NHibernate, which does have a learning curve, but it's not as steep as you might think.

Here are one of the criticisms mentioned:

They are not legacy system friendly meaning they are a nightmare to implement

My current project is pulling data from an Oracle 9i database with a schema and data that has been around for 10+ years. I created a few new tables for my stuff and getting set up and relating to the old stuff was painless.

The most unmaintainable thing about the system is all the business rules encapsulated in stored procedures. Fortunately once I got the gist of those rules, which are also enforced in constraints, they were a snap to implement in code.

Real nightmares

What is a nightmare is the previous app that used this data.  I found this method of the Account class used to persist new instances in that old, legacy app:

Public Function Save() As Int32
    Dim MyDataAccess As New Legacy.BLL.DataAccess
    Dim MyCommand As New OleDbCommand
    Dim sb As New StringBuilder
    sb.Append("LEGACY_ACCT_PKG.SAVE_ACCOUNT")
    MyCommand.CommandText = sb.ToString

    MyCommand.Parameters.Add(New OleDbParameter("pACCOUNTID", OleDbType.Numeric, 22, ParameterDirection.Input)).Value = _ID
    ' ... 20+ more parameters!!!  horror!
    MyDataAccess.isSetGlobalContext = True
    MyDataAccess.RunSP("", MyCommand)
End Function

This is one of hundreds of similar CRUD methods in this app.  Not maintainable.

I don't have a save method in my class, I am using repositories.. the actual "data access" code, common to all the objects I persist is:

public virtual T Save(T entity)
{
    NHibernateSession.Save(entity);
    return entity;
}

To me that was very easy.  NHibernate handles things for me, I don't have to worry about 20 or 30 of the things that a user of that one old-fashioned method has to worry about. Including all that horrible ADO.NET mess.

Query languages considered harmful?

Here's another criticism:

They require an Intermediary Query Language which means extra work for the programmer

Eh... ok, extra work to learn a query language. Getting the gist of NHibernate's query language takes about 5 minutes.  If you want to explore its intricacies, take an hour to parse the relevant docs.    But writing it is pretty easy!  Here's a simple but typical example of a query to pull back all Projects that a certain Employee is a TeamMember of (think of it as populating a grid on a "My Projects" page):

from Project p join fetch p.Team t where t.Employee = ?

which generates SQL something like:

select * from project 
inner join team on project.id = team.projectid 
where team.emplid = :p

Still, there's no requirement that you learn HQL. There are other ways to query: using the Criteria API, straight SQL and in code.  It's okay to decide to avoid pain.

Pain relief

If religion is opium for the masses then object relational mapping would be like Aspirin in the programming world . Not powerful enough to get any programmer high and makes programming easier for about four hours, then real sedation is required to mask the pain. They have even been likened to an unwinnable war in South-East Asia.

This has not been my experience.  What causes me pain is having to deal with the data access myself, or to have queries in my code-behind or worse, in the markup.  It's painful to worry about columns and constraints instead of conceptual relationships and meaning.

Here are some NHibernate resources I found to be really helpful:

Critical to read the documentation
Billy McCafferty's NHibernate Best Practices (I read it four times and it keeps getting better)
Ben Scheirman's NHibernate screencast (very good tips in here)
Setting up NHibernate mapping intellisense
Example application: Cuyahoga CMS source
Example application: CodeCampServer

Jon Galloway touched on it in his blog post today:

The best way to learn is to "aspire to be the dumbest person in the room." Being the smartest person in the room is comfortable - you can feel smug and important as you deign to dole out information. It's also the surest way to avoid learning anything. Surrounding yourself with people who are better informed than you are is a great way to keep learning, but it can take away your confidence in what you've got to say.

Wrong solutions:

• Keep quiet for fear of saying something stupid
• Keep quiet because all those other brilliant people will probably say it soon, and better

Solution:

• Don't write for your own ego, write to share information
• Accept that publishing anything on the internet is one of the best ways to invite constructive criticism for what you think you know

Ah, to invite criticism! To publicly lay intellectually prone with your fleshy bellyful of ideas exposed to the anonymous internet is an incredibly scary thing.

It takes a good deal of confidence to participate online.

On the old altnetconf list, Alex McMahon explains:  He ranks participation online by confidence required

1. Casual chat with close colleagues
2. Meeting/workshop with close colleagues
3. Meeting/workshop with unknowns
4. Writing on internal blog
5. Writing on internal blog and actually telling people about it and referring them to it
6. Writing on internal wiki
7. Releasing a 'proper' guidance document internally
8. (4-7 on the internet)

So join a mailing list list, hang out on Twitter, write the blog and participate in the community.  Another way to pitch in is to contribute to open source software.  I've been working on codecampserver, and even though sometimes I feel I am "the dumbest person in the room" the learning experiences, contacts I've made and pure coding thrills have been invaluable.

My friend is a software developer, but he doesn't work for a software company. He works for a home builder, or a pipe manufacturer, or a retailer.  His job is to deliver software, but delivering software isn't the organization's core competency.

This friend of mine is an in house developer haunted by this reality:

You never get to do things the right way. You always have to do things the expedient way ... Once the core functionality is there, the main problem is solved, there is absolutely no return-on-investment, no business reason to make the software any better. So all of these in house programs look like a dog’s breakfast: because it’s just not worth a penny to make them look nice. Forget any pride in workmanship or craftsmanship you learned in CS323. You’re going to churn out embarrassing junk, and then, you’re going to rush off to patch up last year’s embarrassing junk which is starting to break down because it wasn’t done right in the first place.

On the other hand, a comfortable technical environment means he can focus more on building great software for his users and less on the complexities and headache of struggling through technical challenges.

Are you an in house developer?  What anti-patterns do in house developers uniquely face?