问有没有很好的理由不使用ORM？

EN

近年来，ORM出现了爆炸性的增长，您的更有经验的同事可能仍然在考虑“每个数据库调用都应该通过存储过程”的心态。

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

我想，对于ORM，我能想到的唯一真正的坏处就是它的安全模型不太灵活。

我刚刚重读了你的问题，看起来他们正在复制并粘贴查询到内联中。这使得安全模型与ORM相同，因此与ORM相比，这种方法没有任何优势。如果他们使用非参数化的查询，那么这实际上是一个安全风险。

简而言之，答案是肯定的，确实有很好的理由。事实上，在某些情况下，您就是不能使用ORM。

举个例子，我在一家大型企业金融机构工作，我们必须遵循许多安全指南。为了满足强加给我们的规章制度，通过审计的唯一方法是将数据访问保持在存储过程中。使用ORM工具意味着工具/开发人员可以插入、选择、更新或删除任何他或她想要的东西。存储过程提供了更多的安全性，尤其是在处理客户端数据的环境中。我认为这是需要考虑的最大原因。安全系统。

ORMs的甜蜜点：

ORM对于在适用的情况下自动化查询的95%+非常有用。它们的特别之处在于，您拥有一个具有强大对象模型体系结构的应用程序，以及一个能够很好地处理该对象模型的数据库。如果你正在做一个新的构建，并且在你的团队中有很强的建模技能，那么你可能会用ORM得到很好的结果。

您可能有一些查询最好是手工完成的。在这种情况下，不要害怕编写一些存储过程来处理这个问题。即使您打算将应用程序移植到多个DBMS平台上，依赖于数据库的代码也只占少数。请记住，您需要在任何想要支持它的平台上测试您的应用程序，一些存储过程的一点额外移植工作不会对您的TCO产生太大影响。对于第一个近似值，98%的可移植性与100%可移植性一样好，而且远远好于复杂或性能低下的解决方案，以绕过ORM的限制。

我已经看到前一种方法在一个非常大的(100多年的员工) J2EE项目中工作得很好。

ORM可能不是最合适的的

在其他情况下，可能有比ORM更适合应用程序的方法。Fowler的企业应用程序架构模式有一个关于数据访问模式的部分，它很好地对各种方法进行了分类。我见过的一些ORM可能不适用的情况示例如下：

• 在具有大量遗留存储过程代码库的应用程序上，您可能希望使用面向功能(不要与函数式语言混淆)的数据访问层来包装现有的sprocs。这重用了现有的(因此经过测试和调试的)数据访问层和数据库设计，这通常代表了相当大的开发和测试工作，并节省了必须将数据迁移到新数据库模型的时间。在遗留的PL/SQL代码库周围包装Java层，或者使用web界面重新定位富客户端VB、Powerbuilder或Delphi应用程序通常是一种很好的方法。
• 的一个变体是您继承的数据模型不一定很适合O-R映射。例如，如果您正在编写一个从外部接口填充或提取数据的接口，那么您最好直接使用database.
• Financial应用程序或其他类型的系统，在这些系统中，跨系统数据完整性非常重要，特别是当您正在使用具有两阶段提交的复杂分布式事务时。在supporting.
• High-performance应用程序中，您可能需要更好地对事务进行微观管理，而不是使用ORM来真正调优数据库访问。在这种情况下，可能更好的做法是在较低的level.
• Situations上工作，在这种情况下，您使用的是“足够好”的现有数据访问机制，并且与平台配合良好会比ORM brings.
• Sometimes数据只是数据更有好处--例如，情况可能是您的应用程序使用的是“事务”而不是“对象”，并且这是域的合理视图。这方面的一个例子可能是一个金融包，其中您拥有带有可配置分析字段的事务。虽然应用程序本身可以构建在O-O平台上，但它并不绑定到单个业务域模型，并且可能只知道总账代码、帐户、单据类型和半打分析字段。在这种情况下，应用程序并不知道业务领域模型本身，并且对象模型(除了分类帐结构本身之外)与application.

无关