原始SQL与基于OOP的查询（ORM）？

Question

我在做一个项目，需要经常访问数据库，插入和删除。我应该使用Raw SQL命令还是应该使用ORM技术？该项目可以正常工作，没有任何对象，只使用SQL命令？这是否会影响一般的可扩展性？

编辑：该项目是用户没有提供我的内容，但用户生成内容，并且项目在线的类型之一。因此，内容数量取决于用户数量，如果项目甚至有50000个用户，并且每个用户还可以创建内容或阅读内容，那么最适合的方法是什么？

Answer 1

我想说尽可能以最简单的方式达到目的。 如果使用ORM没有真正的附加优势，并且该应用程序非常简单，那么我不会使用ORM。 如果应用程序确实是处理大量数据集，并且没有业务逻辑，那么我不会使用ORM。

这并不意味着你不应该设计你的应用程序属性，但是，如果使用ORM不会给你带来任何好处，那你为什么要使用它呢？

Answer 2

为了提高开发速度，我会使用ORM，特别是如果大多数数据访问都是CRUD。

这样你就不必开发SQL并编写数据访问例程。

可扩展性不会受到影响，尽管您需要了解自己在做什么（可能会损害原始SQL的可伸缩性）。

Answer 3

我总是会建议在数据访问层使用某种形式的ORM，因为在安全方面投入了大量时间。除非您对自己防范SQL注入和其他漏洞的技能感到有信心，否则这就是不推出自己的原因。

Answer 4

如果项目要么导向： - 数据编辑（如查看数据的简单表和编辑它们） - 性能（设计最快的算法做一个简单的任务）

然后，你可以在你的代码中直接使用sql命令。

你不想做的事情是，如果这是一个大型软件，你最终得到许多类和很多代码，那么做这件事。如果你在这种情况下，并且你在代码中随处散布sql，那么总有一天你会很后悔的。您将很难对域模型进行更改。任何修改都将变得非常困难（除了添加功能或与现有功能无关）。

尽管如此，更多的信息可能会更好： - 频繁出现的频率如何？ - 你需要什么样的表现？

编辑

看来你正在做某种CMS服务。我敢打赌，你不想开始用SQL填充你的代码。 @ teresko的模式建议看起来很有趣，将数据库中的应用程序逻辑与数据库分开（这总是很好），但可以定制每个查询。尽管如此，添加一个填充内存对象的图层比使用数据库结果编写页面要花费更多的时间，但我认为这种差异不应该影响您的情况。

我建议选择一个很好的模式，分离您的业务逻辑和dataAccess，就像@terekso建议。

Answer 5

如果您对ORM没有（或有限）的经验，那么学习新的API需要时间。另外，你必须记住，牺牲'魔术'的速度。例如，即使您只需要Articles表中的标题列表，大多数ORM都会为字段选择通配符“*”。

并且ORMs会在小生境中失败。

大多数ORMs（基于ActiveRecord模式的ORM）在OOP的观点上都存在极大的缺陷。它们在你的数据库结构和类/模型之间建立了紧密的耦合。

您可以将ORM认为是technical debt。这将使项目的开始更容易。但是，随着代码变得越来越复杂，您将开始遇到越来越多的问题，这些问题是由ORM API的限制引起的。最终，你会遇到这样的情况，当不可能对ORM做些什么时，你将不得不直接开始编写SQL片段和entires语句。

我建议远离ORM并在您的代码中实现DataMapper模式。这会让您在您的域对象和数据库访问层之间分开。

Answer 6

这取决于时间表以及您对MySQL和ORM系统的当前知识。如果你没有多少时间，只要做你最擅长的事情，而不是浪费时间学习一组全新的代码。

随着时间的推移，一个像Doctrine或Propel这样的ORM系统可以大幅度提高您的开发速度。当架构仍然发生很大变化时，您不希望花费很多时间重写查询。使用ORM系统，它可以像更改模式文件和清除缓存一样简单。

然后，当设计安定下来时，注意性能。如果您确实使用ORM并且您的代码是可靠的OOP，则一次迁移到SQL一个查询并不是一个太大的问题。

这就是使用面向对象编程的好处 - 像这样的决定并不需要永久地绑定你。