Php 大型、可扩展和可维护的web应用程序中的ORM或SQL？

我知道网上已经有很多关于这个话题的帖子

然而，许多人在谈论它时往往会关注不同的事情。我的主要目标是创建一个易于维护的可伸缩web应用程序。我更欣赏开发和维护的速度，而不是原始性能（或者我可以使用Java）

这是因为我注意到，当一个项目的代码变大时，您必须拥有可维护的代码。当我第一次以程序化的方式编写应用程序时，在没有任何框架的情况下，一个月后它就变成了一场噩梦。我完全迷失在意大利面代码行的丛林中。我根本就没有任何结构，尽管我为了实现一个结构做了很多努力

然后我意识到我必须有正确的结构和代码。我开始使用CodeIgniter。这给了我结构和可维护的代码。很多用户说，框架正在放慢速度，但我认为他们没有注意到这一点。代码必须易于维护和理解

Framework+OOP+MVC使我的web应用程序结构化，因此添加功能不再是问题

当我创建一个模型时，我倾向于认为它代表了一个数据对象。可能是一个表单，甚至是一个表/数据库。所以我想到了ORM（教义）。也许这将是我的web应用程序的又一个伟大的实现，给它更多的结构，这样我就可以专注于特性，而不是重复我自己

然而，我以前从未使用过任何ORM，我只学到了它的基本知识，为什么它好用等等

所以现在我问你们所有人，就像我一样，都在努力寻找可维护的代码，并且知道这有多重要，ORM（条令）对于可维护的代码来说就像framework+mvc+oop一样是必须的吗

我想要比“原始sql更快”建议更多的生活体验建议，因为如果我只关心原始性能，我应该首先放弃框架+mvc+oop，继续生活在编码噩梦中

感觉它非常适合MVC框架，模型就是表格

现在，我在一个文件中有大约150个sql查询，可以做一些简单的事情，比如通过id获取条目、通过名称获取条目、通过电子邮件获取条目、通过X获取条目等等。我认为ORM可以减少这些行，否则我很确定将来会增加到1000行sql。如果我在一列中更改，我必须更改所有列！想想又是一场噩梦。也许这也能给我提供适合MVC模式的好模型

ORM是结构和可维护代码的正确方法吗

很多用户说框架是 放慢速度，但我认为 错过了大局。代码必须 易于维护和维护 明白

如果一个结构良好、高度可维护的系统的性能很差，那么它将一文不值

可维护性是对构建应用程序的程序员有利的东西。原始性能使使用应用程序进行工作（或其他）的真实用户受益。那么，谁的关注应该是最重要的：是谁建立了这个系统，还是谁为它买单

---

我知道这并不是那么简单，因为客户最终会为一个结构糟糕的系统买单——可能会有更多的bug，肯定会有更多的时间来修复它们，有更多的时间来实现应用程序的增强。就像通常情况一样，一切都是一种权衡

我想你错过了这张照片。性能对用户来说是每天都有的，他们根本不关心可维护性。你们是种族中心主义者，你们只关心你们的个人问题，而不关心那个些为系统买单的人。这不全是为了你的方便

---

也许你们应该和用户坐下来，观察他们使用你们的系统一两天。然后，你应该坐在一台与他们使用的电脑（不是开发机器）功率相同的电脑前，花整整一周的时间，除了整天使用你的系统之外，什么也不做。那你就明白他们的意思了

我开始像你一样开发，没有orm工具

然后我为软件开发更工业化的公司工作，他们都使用某种orm映射工具（或多或少都有一些特性）。开发更容易、更快、产生更多可维护的代码等等

但我也看到了这些工具的缺点：性能非常慢。但这主要是对该工具的滥用（在这种情况下是hibernate）

Orm工具是非常复杂的工具，因此很容易滥用它们，但是如果您有使用它们的经验，您应该能够获得与原始sql几乎相同的性能。我想给你三个建议：

• 如果性能不重要，请使用orm工具（选择一个好的工具，我不是用php开发的，所以我不能给你一个名字）
• 确保为您添加的每个功能检查orm工具生成并发送到数据库的sql（例如，感谢日志记录工具）。想想这是否是您编写查询的方式。orm工具的大多数低效来自于从数据库收集的不需要的数据、将唯一的请求拆分为多个请求等。缓慢很少来自工具本身
• 不要在任何情况下都使用该工具。明智地选择何时不使用它（每次进行原始数据库访问时都会降低可维护性），但有时，让orm工具做一些它不是为之开发的事情并不是最糟糕的

编辑： Orm工具对于非常复杂的模型最有用：实体之间的许多关系。在应用程序的配置部分或应用程序的复杂业务部分，大多数情况下都会遇到这种情况。 因此，如果您只有很少的实体，并且它们被更改（重构）的可能性较小，那么它就不那么有用了

两人之间的界限