1.介绍

   为什么使用ORM?

    作者提示：下面是我在业余时间从一本书上摘抄的摘录。

    当下一个十年，我们不会看到银弹。无论在技术上还是管理技巧上，都没有单一的发展。无论在生产力、可靠性还是简易性方面，在十年中，这些技术和技巧都会取得很大的数量级的进步。

    在1986的No Silver Bullet这句圣言现在被Frederick Brooks'放入他的著作中，Brook’s的说一直都是对的，直到大概10年后，即1997,在软件世界中喻为银弹的NeXT's Enterprise Object Framework，世界靠前个对象-关系影射（ORM）框架发布了.虽然不成熟并经常被认为是触犯了软件教条的异教徒,但是仍被很多人普遍接受的ORM技术。事实上，当它被正确使用，它就是软件开发的银弹.随着NHibernate的成熟，ORM中的银弹已经正式地被介绍给.net世界。

    ORM技术最经常的反对者，大体上来说，是使用微软技术的开发者。（因为在过去得十多年里，我一直在研究这个领域，我很高兴能先提高我们）。“如果微软没有开发它，那么就等微软找到正确地方法来开发它”这好像是一条没有成文的规则。在即将到来得C# 3.0中，微软打算使用"LINQ to Entities"来完成它。（是的，正式抛弃使用"LINQ to Entities"）开发者可能继续等待这种技术，或者，有另外一个选择，开始迅速意识到ORM的好处。公平地说，虽然微软没有能开发出来的东西很少，但是自从.NET. Circa 2004面世后，这些没有开发出来东西一直在增多，微软人员（像是母亲）没能创建出来的开放资源工具终于开始达到成熟，这种成熟让人高兴，每一个致力于.NET的人员都要仔细考虑这种成熟。

    这些技术的其它反对者暗示说ORM扼杀了应用程序性能，仅仅在最初的发展阶段给开发带来了巨大的进步。而且，这种争论还在继续，当性能和可维护性的问题开始带来更加值得注意的影响时，使用ORM在项目后期会给项目成功带来严重的损害。三个明显反驳浮现脑海,在回应这些论点。

    首先，作为开发者，使用一个能够支持ORM的框架，例如：NHibernate会提高你的工作性能.你可以少于90％的时间（对，我说的就是少于90％的时间）来开发数据访问代码，然后可以将品质时间花在提高领域模型以及调整性能――假设有必要的话。而且，在综合利用一个简单的压型工具需要很长的时间才能暗示5％的代码，5％的代码会导致95％的性能瓶颈。当在数据访问层就是瓶颈的情况中，为了获得巨大的改善，通常可以作一些简单的调整。顺便提及一声，不用ORM也不会有多少不同。（一定要阅读Peter Weissbrod写的《introductory article to profiling NHibernate applications》）。当ORM构架成为瓶颈并且不能靠调整来改进的情况是很少的，如果适当地分离了数据访问层，就非常容易绕过ORM。

    第二，明确地说，在数据载入行为的所有方面，NHibernate不可思议地控制了它们。对于开发人员的生产力，应用程序灵活性以及应用程序稳定性来说，这一控制给它们产生了有利的影响。当然高速缓冲存储器是可以使用，同时在非ORM解决方案中高速缓冲存储器也是可以使用的。其它out-of-the-box特点，包括lazy loading，对继承的支持，不可变类声明，加载数据到只读属性，支持泛型、存储过程等待。这些强大的特性都在在实际项目中被验证是可行的，另外这些都能够在减少自定义数据访问层的改错和调试时间。（而且，如果你真正地觉得要进入代码，仅仅用NHibernate的开放资源项目就可以了）。

    最后，我想说：那些感觉ORM（例如：NHibernate）在项目后期的维护方面有问题，因而正在使用代码结构体，这样做，只会阻碍任何数据访问层的维护。刚才我说NHibernate是一个银弹，并不是意味着它把正确的应用程序设计的要求去除了。明智地从构架方面来考虑，对于输入一个.NET 应用程序到数据库，可能NHibernate是最可以提供最大维护的解决方案。

    不必说，NHibernate和其它ORM工具一样，减轻了成千上万的代码行和储存程序的维护，因而允许开发者将更多的注意力放在项目的核心上：及时领域模型和商业逻辑。即使你使用一个工具，例如：CodeSmith 或者 LLBLGen Pro,自动地生成你的ADO.NET数据访问层，在你的关系模型中退耦到你的领域模型时，NHibernate会提供足够的灵活性。你的数据库应该是一个“执行细节”，这个“执行细节”被定义来支持你领域模型，而不是用其他方法。这篇文章的剩余部分集中描述了使用已定制的设计模式和“从领域学到的知识”，以此来整合NHibernate到ASP.NET的最优方法。