http://www.cnblogs.com/legendxian/archive/2009/12/30/1635718.html
为什么选择NHibernate
理由1：对象关系映射技术（ORM）的最主要目的是为了解决关系型数据库与面向对象编程技术不匹配的阻抗问题，何为阻抗？通俗的说面向对象的类往往都存在继承和类间关系与数据库的表不是一一对应的，ORM技术可能主要是想解决这个问题。这里需要说一下好多同学和砖家在用ORM的时候还是喜欢先建表，再工具生成和表字段一一对应的所谓实体，个人认为这不是O->R M,而是R->O M,实际上这种做法完全没有体现ORM的最关键思想，还是以前的“表驱动”（通俗解释：先设计表）而非“业务领域驱动”（通俗解释：先设计真正面向对象的业务实体）。因为我的系统业务比较复杂多变，我希望我能尽可能的随心所欲的按照面向对象的思想去设计我的业务实体，充分发挥面向对象思想的作用，不用关心这些设计是否能被持久化，显然NHibernate让我做到了这点，这是我在项目中选择使用ORM技术和NHibernate的最主要目的。
理由2：通过NHibernate和我们的合理设计，实现了对团队人员在开发的时候屏蔽掉数据库访问的技术细节，让我们更专注于业务和UI实现，在绝大多数情况下（复杂的报表查询和大批量操作依然可能需要存储过程实现）不必去关心SQL语句之类的，这对于一个绝大多数都是数据库操作的信息管理系统来说无疑具有很重要的意义。任何一个技术解决方案都不可能覆盖100%的需求，能用20%的精力，解决90%的问题就算是很成功了。
理由3：因为这个系统并不是只给一家医院使用，不同医院所使用的数据库产品是不一样的。从工程角度不能强制要求客户使用固定的数据库产品，NHibernate很大程度上屏蔽了不同数据库产品之间差异，使我不必对不同数据库产品分别写具体实现。
关于效率：“效率YY砖家”说：NHibernate效率低；“大型系统砖家”说：如果并发1W，NHibernate玩不转；弦哥说：
NHibernate这个技术本来长项就不在效率，而在以上3个理由（也许还有一些..），拿NHibernate和直接Ado.Net比效率就像拿c#和汇编比效率一样可笑。
Hibernate+Spring在J2EE里长期作为教科书式的解决方案，无论在国内还是国外都有非常多的大型系统成功案例，从这个意义来说也许Hibernate在效率上并非如此不堪，怎么到了.Net这边就成了效率低下的代名词，貌似说到Hibernate，各位砖家就以效率低一棒子打死，嗤之以鼻。
对于NHibernate的效率弦哥也整了些典型的场景和模拟数据用LoadRunner测了下，并非有各位砖家说的那么夸张，请问各位砖家测过没？
效率问题是一个复杂而综合的问题，如果忽略项目背景，实际业务需求，技术实现方式，以及多种软硬件因素的影响，片面的YY效率无疑是非常不严谨且非常可笑的。弦哥做所谓大并发，大数据量的电信，银行项目也有一些，对于这类项目上线运行的效率瓶颈几乎都在IO，往往都是通过Oracle优化专家和硬件方式解决。比如像上面那位“大型系统砖家”所说的1W并发的项目，同时并发1W是啥概念？没有用小机跑，整啥也白瞎，是吧....也不知道这位砖家见过小机没有....