ORM仍然是"计算机科学的越南"吗？

我昨晚读了这篇文章,我注意到它是从2006年开始的.我可以选择ORM,数据库的任何一种方式,但我只是想知道是否一切都不好杰夫说ORM仍然适用,即使现在考虑帖子是从2006年.

1> dkretz..：

---

它仍然是真的.

如果没有按照预期的方式处理,数据库甚至会超过OO软件.并不打算在它面前设置一些抽象层.

我想到了不透水的抽象层,试图建造一个乐高城堡,所有的部分都被封闭成枕套.SQL很难正确完成.它没有与程序编程共享许多模式,而一方的最佳实践可能与另一方相反.您需要能够在SQL语句中查看每个项目,并且非常清楚它的目的是什么,以及它实际上做了什么.

许多人似乎认为,像马蹄铁一样,近距离足够好 - 如果正确答案突然出现,那就意味着你几乎就在那里.在SQL中,这根本不是真的.

由于这个原因,RoR和ActiveRecord模式当之无愧地赢得了dbms资源的声誉.优化的ActiveRecord设计往往不是次优的SQL设计,因为它鼓励SQL语句分解.

---

实际上,SQL很容易做到......如果你知道你在做什么.关于其他所有技术都可以这么说,所以如果你认为它很难,你不应该试图用ORM来强迫它,你只需要和DBA交朋友(谁会认为程序编码难以理解:))

---

调试和维护问题很少比查看一些joker的链式lambda表达式(包括连接,分组等)更糟糕.与调试存储过程甚至参数化查询相比,这是一个完整的噩梦.

2> Bill Karwin..：

---

是.

面向对象仍然是面向对象的,而Relational仍然是面向集合的.在过去两年中,这两种范式没有任何改变,使它们能够更好地协同工作.

在许多人看来,SQL是丑陋,复杂和令人困惑的.但是,尝试使面向对象的界面执行相同的功能总是更加丑陋,更复杂,并且具有更陡峭的学习曲线.

在所有编程中,灵活性和假设之间存在权衡.框架(例如Rails)试图通过"自以为是"来解决问题.也就是说,它们限制了问题的关系或面向对象方面的灵活性,对数据的结构方式以及使用它可以执行的操作进行了假设.当然,简化问题空间也使解决方案更简单.

另外,发现ORM框架不完整是令人沮丧的,因此SQL中的一些普通操作在给定的ORM中没有解决方案.这也是"自以为是"的框架的结果.

---

根据ohloh.net,Hibernate包含超过800,000行Java和XML代码(不包括注释或其他与Hibernate相关的工具).这个开销真的是必要的,考虑到它和SQL一样难以使用,并没有真正解决问题吗？

3> 小智..：

---

许多Web 2.0公司正在开发关键值商店.所有这些公司都必须经历同样艰难的过程才能使其发挥作用.

如果ORM是"计算机科学的越南",那么建立自己的键值商店可能就是"计算机科学的伊拉克":-)

4> Otávio Décio..：

---

我只能说出我的经历.我使用DAL和DTO,我仍然能够执行非常复杂的查询(连接和所有),而且我还可以在需要时使用SP或自定义SQL.它使我的生活更轻松,我的代码一致,我的截止日期更容易实现.

---

仅仅因为你能做到,并不意味着你应该这样做.你最终学会了一个完整的范式,增加了复杂性,而没有取代其他两个.

5> davetron5000..：

---

我认为从杰夫的结论是正确的假设开始并不一定好; 保持存储过程代码以及基于JDBC的数据层,我可以说这些导致了维护问题,主要与无法理解更高级别的内容有关.

数据库必然是低级的; 它本质上存储数字和字符串.业务逻辑是高级的.这就是我们有抽象的原因.

就个人而言,我认为Rails/ActiveRecord方式是拥有对象/域模型的最佳解决方案,但也能够利用关系数据库.

所以:不要抛弃ORM,但也不要默认它.它是解决某些问题的工具.忽视它将是无知的,并且总是使用它将是傲慢的.