我被要求用 PHP 做一个项目并确保它是面向对象的。我做过 OO 和 PHP，但从来没有两者兼而有之。
OO PHP（继承/多态之外）的主要好处似乎是代码组织。没关系; 我正在这样做。但是我卡住的地方是我是否应该为每个“对象”创建实例。
对我来说（也许我在这里太天真了），Web 应用程序就是要发出非常短的、无状态的请求来更改或检索数据库中的记录。对象不能在请求之间持续存在。因此，从数据库加载数据，从该数据构造一个对象，进行小幅更新，将对象中的数据保存回数据库，然后丢弃该对象，这感觉相当没有意义。加载/保存代码似乎白费了很多工作。[澄清：浪费开发时间，而不是处理时间......不要太在意开销]
另一种选择是拥有一堆单例（或具有静态方法的类），它们只是为数据库层提供一个很好的、有组织的抽象层。我想以这种方式编写代码并没有真正的面向对象的感觉。我错过了什么还是那种风格很好？
是的，您可以将 OO 的好处概括为“代码组织”；但这适用于所有语言（不仅仅是 PHP）。实际上，不仅如此；它是关于你如何看待你的数据结构和算法，即关于它们如何映射到问题域中的概念，它们如何相互关联（所有权、父子、多态性等），以及它们如何公开干净、一致相互接口（封装）。如果这些概念会使您的应用程序受益，并且超过额外的开发时间而不是快速和 hacky 的程序解决方案，那么就去做吧。
我不认为坚持与它有任何关系。
我认为你应该质疑为什么你被要求“确保它是 OO”。这似乎是一个相当随意的要求，没有进一步的理由。通常，方法应该是以最适合要求的风格编写应用程序，而不是任意的突发奇想......
我认为 OOP 只是一种编程风格，与开发应用程序无关。你需要的是一个提供足够抽象层的模式（例如：MVC）。
我的建议是：无脂肪。
它小巧、简单且快速将您带到产品的最小可行版本。它拥有您可能需要的一切（缓存、ORM、CRUD、Captcha ......）并且非常灵活，您可以使用任何模式和自定义目录层次结构。
查看大量文档。唯一的问题是它需要 PHP 5.3。考虑到它提供的选项和灵活性，我认为这是合理的。它真的改变了你的工作方式；你应该明确地试一试。
单例本质上只是添加了一些命名空间糖的全局变量。使用对象和类进行编程有一些主要好处，而这些好处是您无法从直接的过程编程中获得的。一个是继承，正如你提到的。另一个是命名空间——你可以有一个代码将很多压缩到一个单独的包含文件中（在 PHP 等解释语言中比在编译语言中更有意义）。
对象本质上是具有共享状态的函数的集合（尽管单例使其成为全局状态。请注意。）正如您指出的那样，好处主要是该状态由函数透明地共享，而无需在每次调用时都显式地传递它。如果您对每个请求都有各种对共享数据进行操作的函数，并希望它们成为一组通用函数的特殊形式，那么 OOP 可能是一个不错的选择。
由于您的任务是“确保它是面向对象的”，因此我需要一些时间来考虑常见的函数组、相同的概括等。
最后，对象的设置/拆卸时间并不算太糟糕——如果你做得好，它甚至可以在未来节省一些开发时间。
就像生活中的大多数事情一样，答案在中间的某个地方。
今天的应用程序使用 ORM（例如 php 的教义）进行不同类型的优化，更好地理解数据库方法（这对更大的开发团队很重要），更容易更新代码，加入项目的人都知道的抽象层，缓存机制，....
如果您自己做一些较小的项目，使用静态方法的类就很好，但是当更多人参与其中时，您只需要更健壮和标准化的东西。