php - 大型、可扩展且可维护的 Web 应用程序中的 ORM 或 SQL？

Question

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

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

这是因为我注意到当一个项目的代码量增长时，你必须有可维护的代码。当我第一次以过程方式编写我的应用程序时，没有任何框架，仅在 1 个月后它就变成了一场噩梦。我完全迷失在意大利面条代码行的丛林中。我根本没有任何结构，尽管我为实现一个结构而奋斗得很厉害。

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

框架 + OOP + MVC 使我的 Web 应用程序如此结构化，以至于添加功能不再是问题。

当我创建一个模型时，我倾向于认为它代表一个数据对象。可能是一个表单，甚至是一个表/数据库。所以我想到了ORM(学说)。也许这将是我的 Web 应用程序的又一个伟大实现，它提供了更多结构，因此我可以专注于功能而不是重复自己。

但是，我以前从未使用过任何 ORM，我只了解了它的基础知识，为什么它很好用等等。

所以现在我问你们所有人，就像我一样正在为可维护的代码而努力，并且知道这有多重要，ORM(原则)是否像 framework + mvc + oop 一样是可维护代码的必备条件？

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

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

现在我在一个文件中有大约 150 个 sql 查询来做一些简单的事情，比如通过 ID 获取条目、通过名称获取条目、通过电子邮件获取条目、通过 X 获取条目等等。我认为 ORM 可以减少这些行，否则我很确定这将在未来增长到 1000 行。如果我改变一栏，我必须改变所有的人!只是想着它又是一场噩梦。也许这也可以给我适合 MVC 模式的漂亮模型。

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

Answer 1

阿杰，

我投票支持 ORM。我使用 NHibernate。它并不完美，并且有相当大的学习曲线。但是代码更易于维护，更面向对象。除非您喜欢大量重复代码，否则几乎不可能在没有 ORM 的情况下使用 OOP 创建应用程序。它肯定会消除您的绝大多数 SQL 代码。

这是另一件事。如果您要构建一个 OOP 系统，您最终还是要编写自己的 O/R 映射器。您需要调用动态 SQL 或存储过程，将数据作为读取器或数据集获取，将其转换为对象，连接与其他对象的关系，将对象修改转换为 sql 插入/更新等。您将编写的内容是比 NHibernate 或市场上已经存在了很长时间的东西更慢且错误更多。

您唯一的选择实际上是构建一个以数据为中心的程序应用程序。是的，它可能在某些领域表现得更快。我同意性能很重要。但重要的是它足够快。如果您在这里和那里节省几毫秒来执行过程代码，您的用户将不会注意到性能的提高。但是您会注意到糟糕的代码。

ORM 中最大的性能瓶颈在于预取和延迟加载对象的正确方式。这涉及 ORM 的 n 查询问题。不过，这些都很容易解决。您只需要调整对象查询的性能并限制对数据库的调用次数，告诉它何时使用连接等。NHibernate 还支持丰富的缓存机制，因此您有时根本不会访问数据库。

我也不同意那些说性能与用户有关而维护与编码人员有关的说法。如果您的代码不容易维护，那么添加功能就会出现错误并且速度很慢。您的用户会关心这一点。

我不会说每个应用程序都应该有一个 ORM，但我认为大多数应用程序都会受益。也不要害怕在必要时时不时地使用 native SQL 或存储过程与 ORM。如果您必须对数百万条记录进行批量更新或编写非常复杂的报告(希望针对单独的、非规范化的报告数据库)，那么直接使用 SQL 是可行的方法。将 ORM 用于 OOP、事务、业务逻辑和 C.R.U.D。东西，并使用 SQL 处理异常和边缘情况。

我建议阅读 Jeffrey Palermo 关于 NHibernate 和 Onion Architecture 的文章。此外，参加他的敏捷训练营或其他类(class)来学习 O/R 映射、NHibernate 和 OOP。这就是我们使用的:NHibernate、MVC、TDD、依赖注入(inject)。