在最近的几年里，很多程序员把自己的业余时间献给了ORM框架的开发，甚至在有些单位的招聘面试中把是否理解或是能否使用一种ORM构架，作为了一种评价开发人员技能的必要条件。作为一个一线的开发工人，我毫不否认ORM框架对设计模式社区发展作出巨大的贡献，以及对提高开发效率这一目标的成果。
但是请各位读者注意的是，本文是站在大型软件开发的角度上阐述笔者对于ORM构架在大型软件应用上不同环节上的一些观点。因为笔者也在学习ORM构架中，这些观点中可能有一些是片面甚至是不合理的，还请各位读者多提宝贵意见，以便大家一起进步。
在下面的文章中我将简单的和大家探讨在大型软件开发中设计，技术准备，开发，测试修改，生成文档中比较ORM构架的数据持久层与采用通用数据持久层(.net ADO)的一些不同和其引发的一些问题。
设计阶段：
与使用通用的数据持久层相比，ORM构架的数据持久层需要专门的技术论证阶段，具有以下几个方面的不同。
通用的数据持久层因为构架在可靠，稳定的商业用开发构架上，所以无需专门的技术论证。
而使用ORM构架的数据持久层可能需要专业的技术论证。不管使用什么框架，出于风险控制的考虑。需要我们对进行框架一系列的完整的验证，包括可行性,适用度，可靠性，可控制性。
可行性:
我们的项目为什么要使用ORM构架而不是普通的通用数据持久层，改进数据持久层构架的好处在哪里？开发相率提高，可以提高开发人员的技术能力，企业级别技术的储备等等这一切是需要我们认真的调查与分析，否则，轻易的选择使用一个不被所有人认可的构架是无法说服忧心忡忡的PM的
适用度：
我们所选用ORM框架是否完全适用与我们的框架。我们的项目是一个什么样的工程，我们选用的框架是否能满足项目的需要，是否能满足预期风险中数据持久层部分的需要，框架的性能数据报表是否是我们可以接受的。这都是我们要关心的。
可靠性：
我们选用的ORM框架会不会给我们的风险计划表上带来新的附加的风险（使用ORM构架已经给我们带来了一个新的不小的风险）。框架的Bug是否在我们可以接受的范围内，框架的性能曲线是否已经被把握，免费的框架是否会变成一个付费的软件，框架在大规模并发高访问情况下的性能如何..
可控制性:
ORM构架的使用会不会给我们制定开发计划带来不可确定因素，我们的开发人员会不会错误的判断在数据持久层上工作需要的时间与资源，人事的异动会不会需要我们付出新的代价来保证开发的继续进行（新人培训）
总上所述，应用ORM构架的数据持久层除了需要我们打起精神来确认并验证我们的选择，可能还涉及需要写出一个完整的报告，并举行一个大范围的评审会来说明我们的选择。
当然，如果是存在企业级的内部 ORM框架（这很普遍），或是有了成功的开发实例，我们将很大程度减少这方面的麻烦，但是不可否认的是，相对于使用采用通用数据持久层(.net ADO)而言，在设计阶段确定使用ORM构架，我们确实要付出辛苦的努力与代价的（经验上来说统一团队思想，确认使用选定的框架会需要比我们想象的多的时间与精力）。
技术准备：
在这个环节我将阐述一些超出开发组的问题，毕竟一个项目不只是开发组的事情。
1.
如果确认使用ORM构架，那么我们将无可避免的需要面对开发人员技能的问题。我们的框架使所有的开发人员都会熟练使用吗？是否需要组织一个连续的讲座并给开发人员一个专门的学习时间而不是让他们早早进入开发状态？我们的BOSS给我们的时间足够我们用吗？
或许在使用企业级组件的情况下，许多构架师庆幸逃过一个问题。但是要注意到。技术准备的时间不是平白无故的消失了，而是被转嫁了。而不幸的是，ORM构架的培训也许会在不远的将来被千刀杀的BOSS所取消，至少在理论上是存在的。除非BOSS认为SQL基础只似培训相对企业级组件来说简直不值一提。那，你可以只管使用企业级数据持久层组件了，反正出了事都往他头上推就是了。^_^
2.
在写这篇文章的时候是2007年的新春，再过几个月春天就要到了，受够了公司的开发人员也要蠢蠢欲动了。而对我们的项目而言，这是个无法避免的BadTime。新来的伙伴会使用具有我们特色的框架吗？需要专门的给他来个培训与指导吗？这会导致另外一个（或是几个）开发人员的抱怨吗？你认为如何那？
代码开发：
经历了千辛万苦的准备与设计阶段，我们确认了没有将没有什么可以阻挡我们使用我们中意的ORM框架并把这个项目完成，那么我们就经入了开发期。
不得不承认，在这个阶段是ORM构架的数据持久层将展现自己强大优点的好时机。便捷的开发，清晰的代码(作不到这个，选型的构架师基本可以被KO了)使得开发人员体会到了快感。简单的引发对于构架的反思可以极大的鼓励开发团队的学习气氛与交流，有经验的领导人甚至会引发一场提高士气的头脑风暴。
在数据持久层组件框架上的问题或是缺陷会被迅速的发现并被反馈给组件制作组，这无论是对使用者个人还是组件开发人员都是一个极好的帮助。
而这上面所描述的一切面对一成不便的ADO.NET所不能达到的高度。
当然，如果在上面所描述的设计与技术准备阶段准备不足的情况下，也可能是一个完全相反的开发场面。至于有多惨，请读者自己想象把（你见过恐怖片中的地狱吗？）。
测试修改：
代码的修改：
从项目代码的修改上说，ORM构架与普通构架的修改很难比较出哪个比较麻烦。ORM构架虽然强调的其‘映射’能力，但是可惜的是这个‘映射’还没有能够强到能够使我们可以完全傻瓜式的修改。
或许有人会提到普通构架那些该死的SQL语句与存储过程的版本是在很难管理，可是我们也无法回避ORM中常遇到的一大堆配置文件和实体类。或许普通构架在这里不如ORM构架，但是至少他们相距的不是很大，至少没下面我所要说的差距大。
性能问题：
ORM构架最令人诟病的是他的性能问题，尽管各类ORM框架都声称自己的性能已经很不错了，尽管ORM使用了一系列的新概念来弥补，但是我们仍未发现可以接近ADO.net数据的ORM框架，这是ORM的致命伤。
设想一下：如果我们的项目出现了意外，实际能够支配的服务器比预期的要少，我们的压力计算公式有一些小小的偏差，需要我们提供更好的访问性？
如果是普通的数据持久层，我们可以马上进行进行性能优化。
在常见的一些情况下基本不需要改动业务系统，只需要申请专业的数据库分析与优化师来指导修改就可以满足要求。
但是如果我们是ORM构架那？
我们的ORM框架自动生成的代码支持数据优化吗？我们的数据库分析与优化师能够理解并提供优化方案吗？
我们该如何那，是大换血式的更换数据持久层（换用普通的数据持久层会换来很大的提高）还是选择在别的地方苦苦挣扎以换的小小的性能提升？
God，我们如何作，才能换来幸福的生活那！
或许我们可以说大型软件开发中，充足的经费和怪兽级的服务器可以使我们无视这些性能损失。但是为什么不把它们剩下来换取更好的选择那（一次允许携带家人的新马泰双飞游）？
负载控制：
ORM构架还有一个问题就是我们无法很好的调节数据库服务器与业务系统数据库的压力。ORM强调的是映射的实现，而非映射的交互支持力度很小。这就使我们很难调节数据库服务器与业务系统数据库的压力。
比如我可以把业务系统（或数据库）上的排序，关联或是复杂计算交给数据库（或业务系统）来计算，这在普通型数据持久层上只需要简单的修改代码即可实现，但是在ORM构架下却较难实现（需要消耗更多资源）。
生成文档：
当项目交接或是项目完结，ORM构架给我们的文档书写带来了一些特别的感受。
如果我们选用的ORM框架是有使用配置文件的话，那更要恭喜一声。^_^
或许上面列举的在大多数读者看来很简单，或是有许多人有不同的意见。但是类似上面的分析，确是我们在构架时不可掉以轻心或是一带而过的。
因为不正确的认识或是一时的冲动而失去对整体的把握是作为任何一个开发/构架人员的大忌。如果仅凭技术上的优势而不顾一切的使用其，将带来不可预知的风险与代价，而这确实一个开发/构架人员所很难克制的欲望。