大型，可扩展和可维护的Web应用程序中的ORM或SQL？

Question

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

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

这是因为我注意到当项目代码大小增长时，您必须具有可维护的代码。 当我第一次以程序方式编写我的应用程序时，没有任何框架，它只在1个月后成为一场噩梦。 我完全迷失在意大利面条代码行的丛林中。 我根本没有任何结构，即使我努力实施一个。

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

Framework + OOP + MVC使我的Web应用程序结构化，以便添加功能不再是问题。

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

但是，我之前从未使用任何ORM，我只学习了它的基础知识，为什么它的使用效果很好等等。

所以现在我问你们所有像我一样的人都在努力寻找可维护的代码，并且知道这有多重要，ORM（doctrine）是否必须具备可维护代码，就像framework + mvc + oop一样？

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

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

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

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

Answer 1

Ajsie，

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

而这是另一回事。 如果您打算构建一个OOP系统，那么无论如何您最终都会编写自己的O / R Mapper。 您需要调用动态SQL或存储过程，将数据作为读取器或数据集，将其转换为对象，将关系连接到其他对象，将对象修改转换为sql插入/更新等。您所写的将是比NHibernate更慢更多的错误或长期在市场上出现的东西。

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

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

我也不同意那些表示性能与用户有关并且维护是关于编码员的人。 如果您的代码不易维护，那么添加功能将会出错并且速度很慢。 您的用户会关心这一点。

我不会说每个应用程序都应该有ORM，但我认为大多数都会受益。 另外，不要害怕在必要时偶尔使用带有ORM的本机SQL或存储过程。 如果您必须对数百万条记录进行批量更新或编写非常复杂的报告（希望针对单独的非规范化报告数据库），那么直接SQL就是可行的方法。 将ORM用于OOP，事务，业务逻辑和CRUD，并将SQL用于异常和边缘情况。

我建议在NHibernate和Onion Architecture上阅读Jeffrey Palermo的内容。 另外，参加他的敏捷训练营或其他课程来学习O / R Mapping，NHibernate和OOP。 这就是我们使用的：NHibernate，MVC，TDD，依赖注入。

Answer 2

许多用户表示框架正在减慢速度，但我认为他们错过了大局。 代码必须是可维护的，并且易于理解。

如果它的性能是Teh Suck，那么结构良好，高度可维护的系统就毫无价值！

可维护性是使构建应用程序的编码人员受益的东西。 原始性能有益于将应用程序用于其工作（或其他）的真实人员。 那么，他们的关注应该是最重要的：构建系统的人还是那些付钱的人？

我知道这并不是那么简单，因为客户最终会为结构不合理的系统付出代价 - 可能是更多错误，肯定有更多时间来修复它们，有更多时间来实现应用程序的增强功能。 通常情况下，一切都是权衡。

Answer 3

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

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

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

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

• 如果性能不是很关键，请使用orm工具（选择一个好的工具，我不用php开发，所以我不能给你一个名字）
• 确保添加的每个功能，检查orm工具生成并发送到数据库的sql（例如，感谢日志记录工具）。 想一想，如果这是你编写查询的方式。 orm工具的大部分效率低下来自从db收集的不需要的数据，分成多个的独特请求等。缓慢很少来自工具本身
• 不要将工具用于一切。 在不使用它时明智地选择（每次进行原始数据库访问时都会降低可维护性），但有时候，尝试使orm工具执行未开发的操作并不是最糟糕的。

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

少数实体与许多实体之间的界限尚不清楚。 我想说50个不同的类型（sql表，没有连接表）很多，少于10个很少。

我不知道用于构建stackoverflow的是什么，但它必须经过非常仔细的性能测试。

如果您想构建一个负载如此繁重的网站，并且如果您没有这方面的经验，请尝试让您的团队中的某个人已经在这些网站上工作过（使用一组真实的数据进行性能测试）并且代表性数量的并发用户不是一个容易和快速的任务来实现）。 拥有经验的人将大大加快这一过程。

Answer 4

保持稳定性非常重要。 我开发了具有低级超高性能的大规模Web应用程序。 最大的缺点是维护系统，即开发新功能。 如果你慢慢开发，客户将寻找其他系统/应用程序..它的交易。 如果你需要直接对sql进行optmized查询，大多数orms都有功能。 orm本身不是瓶颈。 我会更多地谈论一个好的数据库设计。

Answer 5

我想你错过了这张照片。 每天为用户提供性能，他们完全不关心可维护性。 你是种族中心主义者，你只关心你的个人关注，而不是那些支付系统费用的人。 这不仅仅是为了您的便利。

也许您应该与用户坐下来观看他们使用您的系统一两​​天。 那么你应该坐在一台与他们使用的PC（不是开发机器）相同功率的PC上，花一整个星期做什么，除了整天使用你的系统。 那么你可能会理解他们的观点。