是否有充分的理由不使用ORM？[关闭]

在学徒期间，我将NHibernate用于一些较小的项目，这些项目我大多是自己编写和设计的。现在，在开始一个更大的项目之前，讨论了如何设计数据访问以及是否使用ORM层。因为我仍在学徒生涯中，并且仍然认为自己是企业编程的初学者，所以我并没有真正尝试推动，因为将对象关系映射器用于数据库可以极大地简化开发。开发团队中的其他编码人员比我更有经验，所以我认为我会按照他们的意愿去做。:-)

但是，我不完全理解不使用NHibernate或类似项目的两个主要原因：

1. 可以只使用SQL查询构建自己的数据访问对象，然后将这些查询复制到Microsoft SQL Server Management Studio中。
2. 调试ORM可能很困难。

因此，我当然可以使用很多SELECTs等构建我的数据访问层，但是在这里我错过了自动联接，延迟加载代理类以及如果表获得新列或获得列减少维护工作量的优势。重命名。（更新众多SELECT，INSERT并且UPDATE查询与更新映射配置，并可能重构业务类和DTO的。）

另外，如果您不太了解框架，使用NHibernate可能会遇到无法预料的问题。例如，这可能是信任Table.hbm.xml，您可以在其中设置要自动验证的字符串长度。但是，我也可以想象“简单”的基于SqlConnection查询的数据访问层中的类似错误。

最后，上述那些论点真的是不对基于普通数据库的企业应用程序使用ORM的充分理由吗？他们/我可能错过了其他论点吗？

（我可能应该补充一点，我认为这就像第一个基于“ NET” / C＃的“大型”应用程序，需要团队合作。良好的实践（在单元测试或持续集成等方面在Stack Overflow上被视为很正常） -到目前为止一直存在。）

近年来，ORM的增长呈爆炸式增长，您的经验更丰富的同事可能仍在思考“每个数据库调用都应通过存储过程”。

为什么ORM会使调试变得更困难？无论是来自存储的proc还是来自ORM，您都将获得相同的结果。

我猜想我对ORM唯一真正的弊端就是安全模型的灵活性较差。

编辑：我只是重新阅读您的问题，看起来他们正在复制并将查询粘贴到内联sql。这使得安全模型与ORM相同，因此，与ORM相比，采用这种方法绝对没有优势。如果他们使用未参数化的查询，则实际上会带来安全风险。

简短的回答是，确实有充分的理由。事实上，在某些情况下，您无法使用ORM。

例如，我在一家大型企业金融机构工作，我们必须遵循许多安全准则。为了满足我们制定的规则和法规，通过审核的唯一方法是将数据访问保留在存储过程中。现在有些人可能说这只是愚蠢的，但老实说不是。使用ORM工具意味着该工具/开发人员可以插入，选择，更新或删除他或她想要的任何东西。存储过程提供了更多的安全性，尤其是在处理客户端数据的环境中。我认为这是要考虑的最大理由。安全。

ORM的优点

ORM可用于在适用的情况下自动执行95％以上的查询。它们的特长是在您的应用程序中具有强大的对象模型架构，并且该数据库可以很好地与该对象模型配合使用。如果您要进行新的构建并在团队中具有强大的建模技能，那么使用ORM可能会获得良好的结果。

您可能会遇到一些更好的手动查询。在这种情况下，不要害怕编写一些存储过程来处理此问题。即使您打算跨多个DBMS平台移植您的应用程序，依赖数据库的代码也将是少数。请记住，您将需要在打算支持该平台的任何平台上测试您的应用程序，某些存储过程的额外移植工作不会对您的TCO产生太大影响。初步估计，98％的可移植性与100％的可移植性一样好，并且远胜于复杂或性能差的解决方案以在ORM的范围内工作。

我已经看到，前一种方法在一个非常大的J2EE项目中（100个工作人员年）非常有效。

ORM可能不是最合适的地方

在其他情况下，可能存在比ORM更适合该应用程序的方法。Fowler的企业应用程序体系结构模式中有一节关于数据访问模式，在对各种方法进行分类方面做得相当好。我见过一些ORM可能不适用的情况的示例：

• 在具有大量存储过程遗留代码库的应用程序中，您可能希望使用面向功能（不要与功能语言混淆）的数据访问层来包装现有的存储过程。这重用了现有的（并因此经过测试和调试的）数据访问层和数据库设计，这通常代表了相当大的开发和测试工作，并且节省了将数据迁移到新数据库模型的麻烦。这通常是一种很好的方法，将Java层围绕旧的PL / SQL代码库进行包装，或者使用Web界面重新定位富客户端VB，Powerbuilder或Delphi应用程序。

• 一种变体是您继承不一定适合于OR映射的数据模型的地方。如果（例如）您正在编写一个从外部接口填充或提取数据的接口，那么最好不要使用数据库。

• 跨系统数据完整性非常重要的金融应用程序或其他类型的系统，尤其是当您使用具有两阶段提交的复杂分布式事务时。您可能需要比ORM能够更好地对交易进行微观管理。

• 您想要真正调整数据库访问的高性能应用程序。在这种情况下，最好在较低的级别上工作。

• 使用“足够好”的现有数据访问机制（如ADO.Net）并与平台良好协作的情况比ORM带来的好处要大。

• 有时数据只是数据，例如（例如）您的应用程序正在使用“事务”而不是“对象”，并且这是对领域的明智看法。这方面的一个例子可能是财务包，其中您的交易带有可配置的分析字段。尽管应用程序本身可以构建在OO平台上，但它并不局限于单个业务域模型，并且可能不仅仅知道GL代码，帐户，文档类型和六个分析字段。在这种情况下，应用程序本身并不知道业务领域模型，并且对象模型（除了分类帐结构本身之外）与应用程序无关。

首先-使用ORM不会使您的代码更易于测试，也不一定会在持续集成场景中提供任何优势。

以我的经验，虽然使用ORM可以提高开发速度，但您需要解决的最大问题是：

1. 测试你的代码
2. 维护您的代码

这些问题的解决方案是：

1. 使您的代码可测试（使用SOLID原理）
2. 为尽可能多的代码编写自动化测试
3. 尽可能频繁地运行自动化测试

提到您的问题，您列出的两个异议似乎比其他任何事情都更无知。

无法手动编写SELECT查询（我想这就是为什么需要复制粘贴的原因）似乎表明迫切需要进行一些SQL培训。

我不使用ORM的原因有两个：

1. 公司的政策严格禁止这样做（在这种情况下，我会去其他地方工作）
2. 该项目是极其数据密集型和使用供应商的特定解决方案（如BulkInsert）更有意义。

关于ORM（尤其是NHibernate）的常见拒绝是：

1. 速度

   没有理由为什么使用ORM比手工编码的数据访问要慢。实际上，由于内置于其中的缓存和优化，它可以更快。一个好的ORM将产生一组可重复的查询，您可以优化它们的架构。一个好的ORM还可以使用各种提取策略来有效地检索关联的数据。

2. 复杂

   关于复杂性，使用ORM意味着更少的代码，这通常意味着更少的复杂性。许多使用手写（或生成的代码）数据访问权限的人发现自己在“低级”数据访问库上编写自己的框架（例如，为ADO.Net编写帮助方法）。这些相当于更多的复杂性，更糟糕的是，它们很少得到充分的文档记录或测试。
   如果您正在专门研究NHibernate，则诸如Fluent NHibernate和Linq To NHibernate之类的工具也会使学习曲线变软。

整个ORM辩论让我感到困惑的是，那些声称使用ORM太难/太慢/不管是什么的同一个人，还是对使用Linq To Sql或Typed Datasets感到非常满意的同一个人。尽管Linq To Sql是朝着正确方向迈出的一大步，但与某些开源ORM相比，它仍然落后了很短的几年。但是，用于类型化数据集和用于Linq To Sql的框架仍然非常复杂，要使它们超出（Table = Class）+（基本CRUD）的范围太困难了。

我的建议是，如果最终还是无法获得ORM，则请确保您的数据访问权限与其余代码分开，并遵循“四人行”的编码建议接口。另外，获得一个依赖注入框架进行连接。

（那只蚂蚁怎么样？）

像Hibernate这样的ORM工具有很多常见的问题，有些是阻碍。我对您的项目了解得还不够多。

Hibernate的强项之一是您只能说三遍事情：类，.hbm.xml文件和数据库中都提到了每个属性。对于SQL查询，您的属性位于类，数据库，select语句，insert语句，update语句，delete语句以及支持SQL查询的所有编组和解组代码中！这会很快变得混乱。另一方面，您知道它是如何工作的。您可以调试它。完全可以在您自己的持久层中进行，而不必埋在第三方工具的肠子中。

Hibernate可能是Spolsky的“泄漏抽象定律”的后代。远离人迹罕至的地方，您需要了解该工具的深入内部工作原理。当您知道可以在数分钟内修复SQL时，这可能会很烦人，但您却花了数小时试图哄骗dang工具生成合理的SQL。调试有时是一场噩梦，但是很难说服那些没来过那里的人。

编辑：如果他们不打算对NHibernate转向并且他们想控制自己的SQL查询，则可能要研究iBatis.NET。

编辑2：不过，这是一个危险的大信号：“到目前为止，在堆栈溢出上被视为相当正常的良好实践，例如单元测试或连续集成，还不存在。” 那么，这些“经验丰富”的开发人员，他们在开发中有什么经验？他们的工作安全吗？听起来您可能是对该领域并不特别感兴趣的人，所以请不要让他们扼杀您的兴趣。您需要保持平衡。投入战斗。

我在一个不成功使用ORM的项目上工作。这是一个项目

1. 从一开始就必须水平缩放
2. 必须迅速发展
3. 有一个相对简单的领域模型

使NHibernate在水平分区结构中工作所需的时间比开发了解我们分区方案的超简单数据映射器所花费的时间要长得多。

因此，在我参与过ORM的90％的项目中，这都是非常宝贵的帮助。但是在某些非常特殊的情况下，我认为最好不要使用ORM。

首先，我要说的是，如果正确集成ORM可以使您的开发工作更轻松，但是ORM确实存在一些问题，它们实际上会阻止您实现既定的要求和目标。

我发现在设计对性能有严格要求的系统时，经常会遇到寻找使系统性能更高的方法的挑战。很多时候，我最终得到的解决方案具有很强的写入性能配置文件（这意味着我们写入数据要比读取数据多得多）。在这些情况下，我想利用数据库平台提供给我的功能以达到我们的性能目标（它是OLTP，而不是OLAP）。因此，如果我使用的是SQL Server，并且我知道要写很多数据，为什么不使用批量插入...好了，就像您可能已经发现的那样，大多数ORMS（我不知道是否即使是单个插件也没有能力利用平台特定的优势（例如批量插入）。

您应该知道可以混合使用ORM和非ORM技术。我刚刚发现，在少数情况下，ORM无法满足您的要求，因此您必须针对这些情况进行解决。

当需要更新5000万条记录时。设置一个标志或其他。

尝试使用ORM进行此操作，而不调用存储过程或本机SQL命令。

更新1：尝试仅使用其几个字段来检索一条记录。（当您有一个非常“宽”的表时）。或标量结果。ORM也很烂。

更新2：似乎EF 5.0 beta有望进行批量更新，但这是一个非常热门的新闻（2012年1月）

对于非平凡的基于数据库的企业应用程序，确实没有理由不使用ORM。

除了功能：

• 通过不使用ORM，您正在解决的问题已经被大型社区或拥有大量资源的公司反复解决。
• 通过使用ORM，数据访问层的核心部分将从该社区或公司的调试工作中受益。

为了使观点更具说服力，请考虑使用ADO.NET与编写代码以自行解析表格数据流的优点。

我已经看到了对如何使用ORM的无知，证明了开发人员对ORM的蔑视。例如：渴望加载（我注意到您没有提及）。假设您要检索一个客户及其所有订单，以及所有这些订单明细项目。如果仅依靠延迟加载，则您将摆脱ORM的经验，并提出以下观点：“ ORM速度很慢”。如果您学习如何使用紧急加载，则将在2分钟内完成5行代码，而您的同事将需要半天的时间来实现：对数据库的一次查询并将结果绑定到对象的层次结构。另一个示例是手动编写SQL查询以实现分页的痛苦。

使用该ORM的可能例外是，如果该应用程序是一个ORM框架，该框架旨在应用特殊的业务逻辑抽象，并且可以在多个项目上重用。但是，即使是这种情况，也可以通过使用这些抽象来增强现有的ORM来更快地采用。

不要让高级团队成员的经验将您拖向计算机科学发展的相反方向。我从事专业已有23年的发展经验，其中一个常数就是老派对新事物的鄙视。ORM对SQL就像C语言对汇编语言一样，您可以打赌，与C ++和C＃对等的方式即将到来。新行代码的一行等于旧行的20行。

我认为，也许当您在更大的系统上工作时，可以使用CodeSmith之类的代码生成器工具代替ORM ...我最近发现了这一点：Cooperator Framework可以生成SQL Server存储过程，还可以生成您的业务实体，映射器，网关， lazyload和C＃中的所有内容...检查一下...它是由阿根廷的一个团队编写的...

我认为这介于编码整个数据访问层和使用ORM之间。

我个人（直到最近）一直反对使用ORM，并习惯于编写封装所有SQL命令的数据访问层。对ORM的主要反对意见是，我不相信ORM实现能够编写正确的SQL。而且，从我以前看过的ORM（主要是PHP库）来看，我认为我是完全正确的。

现在，我的大部分Web开发都是使用Django，而且我发现所包含的ORM确实很方便，并且由于数据模型是按照其术语首先表达的，而后来才用SQL表示，因此它确实可以很好地满足我的需求。我敢肯定，扩展它并不会很困难，并且需要用手写的SQL进行补充。但是对于CRUD而言，访问已绰绰有余。

我不知道NHibernate；但是我想它对于您所需要的大多数也“足够好”。但是，如果其他编码人员不信任它；对于每个与数据相关的错误，它将是主要的怀疑者，这使得验证变得更加乏味。

您可以尝试在工作场所逐步引入它，首先关注小型“显而易见”的应用程序，例如简单的数据访问。一段时间后，它可能会用在原型上，并且可能不会被替换...

如果它是OLAP数据库（例如，用于报告/分析的静态，只读数据等），则不适合实施ORM框架。相反，使用数据库的本机数据访问功能（例如存储过程）将是更可取的。ORM更适合事务（OLTP）系统。

我认为有很多理由不使用ORM。首先，我是.NET开发人员，我喜欢坚持使用出色的.NET框架提供给我的东西。它完成了我可能需要做的所有事情。这样一来，您就可以采用更标准的方法，因此，在同一项目中从事该项目的其他任何开发人员都有更大的机会来挑选并运行该项目。Microsoft已经提供了足够的数据访问功能，没有理由放弃它们。

我已经成为专业开发人员已有10年了，领导了多个非常成功的百万美元以上的项目，而且我从未编写过需要能够切换到任何数据库的应用程序。您为什么要客户这样做？仔细计划，选择适合您需要的数据库，然后坚持使用。就个人而言，SQL Server能够执行我需要做的任何事情。这很容易，而且效果很好。甚至有一个免费版本，最多支持10GB数据。哦，它对.NET很棒。

我最近不得不开始着手几个使用ORM作为数据层的项目。我认为这很不好，而且我不得不无故学习任何其他用法。在客户确实需要更改数据库的极少见的情况下，与花费大量时间与ORM提供者相比，我本可以轻松地对整个数据层进行重新处理。

老实说，我认为ORM有一个真正的用途：如果您要构建像SAP这样的应用程序，那么它确实需要能够在多个数据库上运行的能力。否则，作为解决方案提供者，我告诉客户此应用程序旨在在此数据库上运行，事实就是如此。再经过10年和无数次申请之后，这再也不是问题。

否则，我认为ORM适用于不了解少即是多的开发人员，并认为他们在其应用程序中使用的更酷的第三方工具越好，他们的应用程序就会越好。我会将这样的事情留给死忠的极客，同时我开发出更多出色的软件，同时任何开发人员都可以选择并立即提高生产力。

运行性能是我能想到的唯一真正的缺点，但是我认为这比ORM节省您的开发/测试/测试时间要公平得多。而且在大多数情况下，您应该能够找到数据瓶颈并更改对象结构以提高效率。

我以前没有使用过Hibernate，但是我注意到一些“现成的” ORM解决方案中的一件事是缺乏灵活性。我敢肯定，这取决于您使用哪种工具以及需要做什么。

ORM有两个令人担忧的方面。首先，它们是由其他人编写的代码，有时是封闭源代码，有时是开放源代码，但范围很大。其次，他们复制数据。

第一个问题导致两个问题。您依赖于局外人代码。我们都这样做，但是选择此举不应掉以轻心。如果它不能满足您的需求，该怎么办？您什么时候会发现？您住在ORM为您绘制的框内。

第二个问题是两阶段提交之一。关系数据库正在复制到对象模型。您更改对象模型，它应该更新数据库。这是两阶段提交，不是最容易调试的事情。

我建议阅读此书以了解ORM的缺点。

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

就我自己而言，我发现ORM对我编写的大多数应用程序非常有用！

/艾格

我对Hibernate的经验是它的语义很微妙，当出现问题时，很难理解它到底是怎么回事。我从一个朋友那里听说，通常是从Criteria开始，然后需要更多的灵活性并需要HQL，后来又注意到毕竟需要原始SQL（例如，Hibernate没有联合AFAIK）。

同样，使用ORM，人们很容易过度使用现有的映射/模型，这导致存在一个对象，其中的许多属性没有被初始化。因此，查询后，内部事务Hibernate会进行其他数据提取，从而导致潜在的速度降低。同样令人遗憾的是，休眠模型对象有时会泄漏到视图体系结构层中，然后我们看到LazyInitializationExceptions。

要使用ORM，应该真正了解它。不幸的是，人们很容易就觉得这很容易，而事实并非如此。

本身不是要回答，我想改一下我最近听到的一句话。“一个好的ORM就像雪人，每个人都在谈论一个，但是没人能看到它。”

每当我把手放在ORM上时，我通常都会发现自己在为该ORM的问题/局限性而挣扎。最后，是的，它可以满足我的要求，它写在那个糟糕的文档中的某个地方，但是我发现自己又失去了一个小时，我再也无法得到。任何使用过nhibernate，然后在PostgreSQL上熟练使用过nhibernate的人都会理解我的经历。不断感到“此代码不受我控制”的感觉真是太糟糕了。

我不会指责或说它们很糟糕，但是我开始考虑我要付出的只是在单个表达式中实现CRUD自动化。如今，我认为我应该使用较少的ORM，也许创建或找到一个使数据库操作最少的解决方案。但这只是我。我相信在这个ORM领域中有些事情是错误的，但是我不够熟练，无法表达它。

我认为使用ORM仍然是一个好主意。特别要考虑您所给的情况。从您的帖子中听起来，您在数据库访问策略方面经验更丰富，我会使用ORM提出。

对于＃1没有参数，因为复制和粘贴查询以及在文本中进行硬编码没有灵活性，而对于＃2，大多数orm会包装原始异常，将允许跟踪生成的查询，等等，因此调试也不是火箭科学。

至于验证，除了内置验证之外，使用ORM通常还可以使开发验证策略的时间更加轻松。

编写自己的框架可能很费力，而且常常会遗漏一些东西。

编辑：我想提出一点。如果您的公司采用ORM战略，那么它将进一步提高其价值，因为您将制定使用和实施的准则和实践，并且每个人都将进一步增强他们对所选框架的了解，从而减轻您所提出的问题之一。此外，您还将学习什么情况有效，什么不可行，最终将节省大量时间和精力。

每个ORM，甚至是一个“好的” ORM，都带有一定数量的假设，这些假设与该软件用来在应用程序层和数据存储之间来回传递数据的基础机制有关。

我发现对于中等复杂的应用程序，解决这些假设通常比花简单的编写更直接的解决方案（例如查询数据和手动实例化新实体）要花费更多的时间。

特别是，一旦您使用多列键或其他中等复杂的关系，而这些关系又超出了ORM在下载代码时为您提供的方便示例的范围，您很可能会遇到麻烦。

我承认对于某些类型的应用程序，尤其是那些具有大量数据库表或动态生成的数据库表的应用程序，ORM的自动魔术过程可能会有用。

否则，使用ORM会陷入困境。我现在认为它们基本上是一种时尚。