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.

1 Answer 1


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.