本机查询和存储过程与 ORM答案

【问题标题】：Native Queries and Stored Procedures vs ORMs本机查询和存储过程与 ORM
【发布时间】：2011-12-11 08:24:55
【问题描述】：

随着像 LINQ to SQL 和实体框架这样的 ORM 越来越受欢迎，这让我对使用本机查询和存储过程产生疑问。

我天生就喜欢 SQL 以及与 RDBMS 的直接联系。我喜欢对所发生的事情进行纯粹的控制，并且我喜欢我的跟踪准确地显示我在代码中调用的内容（存储过程等）。

但是我错过了 ORM 的哪些好处？仅仅是快速的发展过程吗？不需要管理包含的数据库和对象？

不使用 EF 和 LINQ to SQL 我错过了什么？

【问题讨论】：

【解决方案1】：

我认为这里最大的影响是生产力；使用 EF（或任何其他 ORM）构建简单的 CRUD 接口非常简单。但是，当您不完全了解正在发生的事情时，就会出现问题。

例如，假设有一个大对象，有几个子集合； ORM 理解数据是如何集成的，并且必须返回非规范化的数据才能实现该对象。这可能会对数据传输产生巨大影响。

另一件事是关于性能。也许你会得到一个用户界面，它应该做很多计算，或者更新一个大对象及其依赖项。在这种情况下，我建议使用本机访问（存储过程等）来释放您的 RDBMS 全部潜力。

总结：简单的接口，ORM；中到复杂的接口、存储过程。

【讨论】：

我喜欢你的回答。知道我的原生 SQL 方法在所有领域都足够了，这让我感到很自在。即使我确实在较小的项目上重新发明了众所周知的轮子，直接控制也让我高枕无忧。
这就是我的方法；对于我的应用程序中的每个简单 UI，我都使用纯 EF 对象，对于 n-n 关系、报告和其他复杂接口，我依赖存储过程，最终接收到一个 XML 参数，以实现大量数据和核心性能/事务一致性。