Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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