ORM 与手工编码的数据访问层

Question

我有点害怕问这个问题，因为它可能会引发一场宗教 war ，所以我想非常清楚我在寻找什么。我正在寻找您为什么会或已经以某种方式跳跃的原因，以及要添加到我列表中的项目。我正在寻找大票，大爆炸元素。此外，如果它们确实相关，则可能是特定于产品的项目。在这一点上，我正在尝试评估 ORM 与手动，而不是产品 A 与产品 B。

ORM的优势

- 快速编码和低维护(在某些/大多数情况下)
- “免费”的附加功能(无需开发人员的努力)

手工编码的优势

- 更高效(在运行时，也许不是在开发时？)
- 更少的复杂层
- 大多数 ORMS 似乎都在为仅限于存储过程而苦苦挣扎

为了全面披露，我真的不喜欢在我认为合适的情况下对我无法直接修改的数据库执行代码的“东西”的想法，但我可以看到 ORM 潜在的大量开发时间优势。

它可能也值得注意我在一个.Net世界

[编辑]
(Using an ORM or plain SQL? 上的问题似乎回答了许多问题并强化了关于性能的观点)

所以，稍微改变我的问题

有没有人在早期使用 ORM 构建应用程序，然后逐渐用手工编码的 DAL 代替？这种方法的缺陷是什么？

[进一步编辑 - 现在进入问题的核心]
让一个网站能够对我的数据库执行任何 SQL 是可怕的。如果所有访问都是通过 sprocs 进行的，那么我的数据库将处于良好、安全、舒适的隔离状态。仅使用 sprocs 可以消除很多(如果不是全部)SQL 注入(inject)攻击向量。对此有何评论？

Answer 1

我们最初使用 JPA 编写了一个应用程序，自从它投入生产之日起我们就后悔了。 ORM 进行的数据库调用量是天文数字，因此我们现在已经开始使用 Spring 的 JDBC 帮助程序类使用良好的老式 JDBC 逐步重写应用程序的过程。从 ORM 开始的缺陷是我们花了很多时间学习 JPA，最终我们必须用 JDBC 替换它，这样我们的应用程序就可以更具可扩展性，而无需向我们的 Oracle RAC 添加 3 个其他节点。因此，如果您平衡它，JDBC 的控制和精度值得您编写额外的代码行。此外，大多数人不理解 SQL 不是可以生成和预期执行的东西。这是必须编写和调整才能获得最大性能的东西。