ORM与手工编码的数据访问层 [英] ORM vs Handcoded Data Access Layer

问题描述

我有点害怕问这个问题，因为这可能会引发一场宗教战争，所以我想真正弄清楚我在寻找什么.我正在寻找一个原因，您可能会或已经以一种或另一种方式跳转，并且还希望将某些项添加到我的列表中.我在找大票，大爆炸物品.另外，如果某项产品确实相关，则可能是针对某项产品的.在这一点上，我正在尝试评估ORM与手动，而不是产品A与产品B.

I'm a bit scared to ask this question as it may start a religous war so I want to be really clear on what I'm looking for. I'm looking for a reason(s) why you would or have jumped one way or the other and also for items to add to my lists. I'm looking for the big ticket, big bang items. Also, items specific to a product, maybe, if they are really relevant. At this point I'm trying to evaluate ORM vs Manual not product A vs product B.

ORM的优势

 - Quick to code and low maintenance (in some/most scenarios) 
 - Additional features for "free" (no developer effort)

手动编码的优势

 - More Efficient (at runtime, maybe not at dev time?)
 - Less layers of complexity
 - Most ORMS seem to struggle with being retricted to sprocs only

出于全面披露的目的，我真的不喜欢某些"对我无法直接修改的 my 数据库执行代码的想法，如果我认为合适，但我可以看到ORM潜在的大量开发时间优势.

In the interests of full disclosure, I really don't like the idea of "something" executing code against my database that I can't directly modify, if I see fit but I can see the potentially massive development time advatages of an ORM.

可能还值得注意的是，我在.Net世界中

Its probably also worth noting I'm in a .Net world

(使用ORM或纯SQL的问题?似乎可以回答许多问题问题，并强调有关性能的要点)

[edit] (the question at Using an ORM or plain SQL? seems to answer many of the questions and reinforce the point about performance)

所以，要稍微改变一下我的问题

So, to alter my question slightly

是否有任何人在早期使用ORM构建了一个应用程序，然后逐渐替换为手工编码的DAL?这种方法的陷阱是什么?

Has any built an app using an ORM in the early stages and then gradually replaced with with a handcoded DAL? What were the pitfalls of this approach?

[进一步编辑-立即探究问题的核心] 拥有一个网站能够对我的数据库执行任何SQL的情况令人恐惧.如果所有访问都是通过存储库进行的，那么我的数据库将处于良好，安全，舒适的隔离状态.仅使用sproc会删除很多(如果不是全部)SQL注入攻击媒介.对此有何评论?

[Further Edit - getting to the heart of the problem now] Having a website be able to execute any SQL against my database is scary. If all access is through sprocs my database lives in nice, safe, comfortable isolation. Using exclusively sprocs removes a lot of, if not all, SQL injection attack vectors. Any comments on that?

推荐答案

自从JPA投入生产以来，我们最初使用JPA编写了一个应用程序，对此我们感到后悔. ORM进行的数据库调用数量是天文数字，因此我们现在已经开始使用Spring的JDBC helper类使用良好的JDBC进行逐段重写应用程序的过程.从ORM开始的陷阱是，我们花了大量时间学习JPA，最终，我们必须用JDBC替换它，这样我们的应用程序才能具有更大的可伸缩性，而无需在Oracle RAC中添加其他3个节点.因此，如果您将其平衡，那么JDBC的控制和精确度值得您编写额外的代码行.而且，大多数人不了解SQL并不是可以生成和预期执行的东西.必须进行一些编写和调整才能获得最佳性能.

We initially wrote an app using JPA ever since the day it went into production we have regretted it. The amount of database calls being made by the ORM were astronomical, so we have now started the process of piece-meal rewriting the application using good ol' fashioned JDBC utilizing Spring's JDBC helper classes. The pitfalls of starting with an ORM is that we spent a good deal of time learning JPA and at the end of the day we have to replace it with JDBC so our application can be more scalable without adding 3 other nodes to our Oracle RAC. So if you balance it out, the control and precision of JDBC was worth the extra lines of code you have to write. Also, most people do not understand that SQL is not something that can be generated and expected to perform. It is something that has to be written and tweaked to gain maximium performance.

这篇关于ORM与手工编码的数据访问层的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！