I boiled down several lists of pros and cons of using NHibernate into this simplified list. There are only 2 pros, but they’re huge and I showed how all the cons could be easily mitigated. Let me know if you have any questions.
1) Speeds development.
a. Writing update/insert statements and mapping query result fields to/from object members is slow, tedious, and prone to error. Letting NHibernate do this saves a significant amount of time and lets the developer focus on business logic.
b. The number of unit tests needed to be created and maintained is reduced because all the crud statements go through a common dll.
2) Makes data access more abstract and portable. The ORM implementation classes know how to write vendor-specific SQL, so we don’t have to. This provides a level of abstraction which helps isolate the app from the database. If we need to change our database schema or if we go to another brand of database, we minimize the impact on the code we have to modify in our applications.
1) NHibernate has a learning curve, but examples are well documented in current 3G projects.
2) NHibernate might be slightly slower because it has to generate sql on the fly, but the performance hit should be insignificant.
3) NHibernate might autogenerate slow sql statements. However, we generate the get statements, so NHibernate isn’t involved with those. Therefore, NHibernate should only be autogenerating update/insert/deletes, which are straightforward. Just to be sure, we can add logging for every sql statement NHibernate generates with verbose logging.
4) Using NHibernate to create a strict separation of tables/classes not good for bulk updates/inserts/deletes (i.e. updating 1,000 objects with new data; moving 1,000 rows from one table to another; etc). Not a problem because we should just execute a raw sql statement for those use cases.
5) Using NHibernate to create a strict separation of tables/classes not good for reporting. Not a problem because we can (and should) create separate business objects for each business use case. A business object does not have to map directly to a table (in fact, with this database design, it probably shouldn’t). For example, a multiple join select statement can be run to generate a collection of reporting objects that can be bound to a report/grid.
NHibernate vs Entity Framework: http://foofish.org/blog/?p=57
NHibernate vs Entity Framework performance test: http://gregdoesit.com/2009/08/nhibernate-vs-entity-framework-a-performance-test/