Take the 2-minute tour ×

So, I've been evaluating Entity Framework and NHibernate (I'm not looking for an EF vs. NH battle here, though!).

One thing that I see come up very often is that NHibernate is recommended for "legacy"/brownfield database projects, and lighter-weight ORMs (Dapper, etc) are sometimes recommended for newer dbs.

I will be applying my ORM to a brownfield database. What specific features of NHibernate make it so widely recommended for "legacy" dbs. (I have never heard anyone say "here's why NHibernate is better for legacy DB's -- I really want to know that, so that I can evaluate NHibernate appropriately)

And by the way, what is the definition of legacy here? Do people mean

  • "databases that are not well normalized"?
  • "databases that are being accessed through non-ORM means, such as SQL queries or stored procs? (or)
  • not talking about the database at all, but referring to classic 2 tier systesms (or 2-tier web apps, where there is thick session state, and no application tier)?
  • Any database that is isn't a noSQL database?

If it's of any use the discussion. I will be using this ORM to build distributed, multi-tier software. So I think that a lot the stateful features in ORMs -- like change tracking, etc, will not matter to me very much.

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

I'm not familiar with EF, so it's possible that what I'm about to mention exists in EF as well.

I'm working with Priority ERP, which has a legacy database. What does legacy means in this case?

  • No foreign keys
  • Sometimes being forced to create both a sequence numeric primary key and a unique key due to Priority ERP
  • Table and field names limited to 20 characters capital letters only
  • Fake floating numbers (field stores int 10500, actual value is 10.500)
  • Booleans are stored as one character varchar field, where "Y" is true, and anything else is false (and I do mean anything else, some Priority ERP procedures use empty string, some "N")
  • Dates and times are stored as number of minutes since 1-1-1988 (only minutes, no ability to store seconds)
  • Having to work with prebuilt tables that were built in the 80's and because of no foreign keys the relationship between the tables is awkward to say the least
  • Some tables have FIELD1...FIELD10 per row instead of a join table, which makes it impossible to do normal queries on the table.
  • No nulls allowed in any field
  • Every table, even with zero data, has an empty row filled with default values that is used as a replacement for outer join because of the no nulls setting.

NHibernate plus ActiveRecord enables me to support all those limitations pretty easily:

  • Built in extension points when handling CRUD operations
  • Ability to map the actual field contents on a field and convert it back and forth with a property
  • Letting me define almost any mapping between entities
  • Creating a custom query with HQL to do exactly what I need, even if I can't map the relationships between the entities
share|improve this answer
add comment

Your Answer


