如果我使用存储过程，我会使用ORM吗？

Question

如果我使用存储过程，我可以使用ORM吗？

编辑：

如果我可以使用ORM，那是否会破坏使用ORM的部分数据库不可知原因？换句话说，如果我使用存储过程将自己绑定到特定数据库（或假设错误），为什么还要使用ORM呢？

Answer 1

使用ORM访问存储过程是ORM的最佳用途之一。它将为您提供强类型对象，同时您仍然可以完全控制SQL。

Answer 2

根据我的经验，我会让ORM处理'CRUD'操作，并将专业工作留给存储过程。通常，使用“CRUD”操作的存储过程是过度的，并且让ORM处理它，可以大大提高您的工作效率。

Answer 3

是的，您可以，所有主要的ORM都支持存储过程。

至于您的假设，您特别正确，当您使用ORM存储过程时，您将项目耦合到特定数据库。但实际上99％你不需要更改数据库提供程序，所以在这种情况下你使用ORM不从具体的数据库提供程序中抽象，而是帮助自己处理对象关系映射任务 - 这是一个主要的ORM任务以及最初制作的ORM。

Answer 4

这提出了一个有趣的观点。

一旦你有ORM和相对简单的查询，你为什么需要存储过程？ SP与数据库密切相关。 ORM使您不必维护大量特定于DB的代码。可以隔离和管理 特定于数据库的内容。

我建议ORM是一个降低复杂性的绝佳机会，并将所有处理放在它所属的代码中。

使用数据库获取最佳效果 - 存储数据。

将您的应用程序用于最佳处理 - 处理数据。

Answer 5

您可以同时使用ORM功能和存储过程功能。特别是在适合您之前使用ORM，但如果您在性能方面遇到一些问题或者需要一些低级调整 - 请在业务逻辑中包含存储过程。

Answer 6

是的，你可以，但你会花一些时间来研究ORM围绕存储过程提供的功能。

大多数将允许您运行返回强类型对象/实体的存储过程。更高级的ORM将允许您插入存储过程以执行CRUD操作（因此您的通用查询，删除等通过存储过程而不是动态查询）。

通常，ORM非常适合生成即席查询和获取强类型实体，但具有强大的存储过程支持，这样可以让您（有时）更轻松地访问RDMS的本机功能，而这些功能可能不会作为头等类公开ORM中的公民 - 特别是如果ORM支持许多数据库引擎。

跟进编辑：

通常你会想要使用ORM提供的ad-hoc查询引擎，但正如我前面提到的那样 - 有时候你想使用ORM未公开的功能进行查询。

强类型实体的好处是非常宝贵的，因为它意味着您通常拥有域对象，而不是数据读取器，数据表等。您可以在已检索的实体中干净地封装行为和逻辑。

其他好处的列表确实很长 - 例如，使用LightSpeed ORM（以及大多数其他），您的实体将支持标准绑定接口，错误报告界面，验证等。在查询方面，您将失去懒惰加载等，除非你自己写。

Answer 7

数据库“不可知”（？）不是使用ORM的唯一原因。但是，您可以利用DB独立于99％的与DB的交互，以及1％（或2％或10％或其他）您可能需要存储过程来提高速度/清晰度/复杂性。如果您更改了DB，则需要重写它们。

Answer 8

我在工作中使用了很多netTiers，我们让它为我们生成存储过程。这些只处理基本的CRUD操作，但它们非常快，并且节省了大量的时间。 netTiers还允许我们使用这些过程创建自定义存储过程并生成数据访问代码。

Answer 9

您可以，但许多更高级的ORM功能往往变得更加麻烦。像iBatis之类的东西很容易与存储过程集成，而像（N？）Hibernate这样的更复杂引擎的更复杂的特性就像动态SQL的生成和大字段的延迟加载可能变得比它们更麻烦值得。

Answer 10

我相信任何可以让你免于重做工作并集中精力解决问题的工具都是有效的。在进行基本的CRUD操作时，ORM似乎就是那个工具 - 即使使用SP来更好地实现一个要求（比如在钉子上使用锤子，它只是正确的工具）。

重点是：没有黑色或白色，只有灰色等级。非常缺乏编码和编码错误的应用程序使用“数据库不可知”的借口来解释数据库资源的过度使用。在许多情况下，与数据库紧密相关也不是很好。目标是：在不需要浪费客户IT资源的同时获得最大的“数据库不可知性”。

没有'旧与新'，只是人们说极端'纯'方法更好。我真的不相信。我相信，与任何工具一样，“最佳”（注意引号）方法使用ORM，直到仍然是使您的数据访问的正确工具。当你达到浪费资源并降低可扩展性和'值得生活'（我忘记了与葡萄牙语'vidaútil'相当的英语表达）的TI资源时，在你的ORM中使用SP。或者，换句话说，当用于手头的处理时，使用SP来指甲钉。