php - 没有 ORM 或 API 框架的模型架构

Question

首先让我说，我意识到这个问题含糊并且没有单一答案。尽管如此，我还是非常感谢 StackOverflow 社区的洞察力。出于本网站的目的，将根据是否遵守规范及其障碍地址来选择答案。

概览

我正在启动一个主要是 RESTful API 的项目，目前有大约六个模型。但是，他们也将是一个网站。目标是大致遵循 MVC 架构，以便站点和 API 使用相同的代码库。我的计划是大量使用模型，并在 Controller 上点亮(或根本不点亮)。 JSON (API) 和 HTML(网站)的 View 会有所不同。

规范

• 没有 ORM。我现在嫁给了 MySQL + PHP。虽然这以后可能会发生变化，但我很乐意将两者结合起来，因此不需要 ORM。
• 平衡抽象。我相信胖模特。但是，根据上述内容，我不需要为我编写的查询。尽管如此，我还是想封装模型属性。
• 速度。由于该站点将主要利用 API，因此速度是基石。恕我直言，我宁愿避免全栈框架的重量。

障碍

• 如果模型是自定义类，加载多个模型的最佳方式是什么。我更喜欢延迟加载，但不以牺牲性能为代价。没有预优化，如果没有在每个页面顶部半打瞌睡的 require() 语句，什么是加载多个模型的干净方法。
• 平衡抽象，我不想在每个模型中为每个可能的查询创建 getX() 方法。然而，我想避免在我的观点中写查询。那么我如何才能在抽象和仍然尊重 MVC 范式之间干净利落地平衡呢？

如果存在着重于模型抽象的东西(它可能确实如此)，请指出那个方向。但是，我熟悉 CakePHP、Frapi、Code Ignitor 并阅读了 Doctrine。我认为这些不符合规范。

Answer 1

查看 Eric Evans 的 Domain-Driven Design ，或免费在线 redux Domain-Driven Design Quickly .

规范

• 如果您不想，则无需使用 ORM。或者您有时可以使用 ORM，或者根据需要在其他时间使用自定义 SQL。无论您在这些方法中编写什么代码来查询数据库，都是一个实现细节，应该由 Model 类的面向公众的接口(interface)抽象出来。

• 您应该编写模型方法来封装与您的应用程序相关的逻辑操作。也就是说，您的类和方法是基于更高级别的业务需求，而不是作为低级别的 CRUD 操作。

• 使用模型不需要大写 F 的框架。查看Page Controller模式，恕我直言，它比框架中常见的前端 Controller 模式更符合 PHP 约定。

障碍

• 关于延迟加载，试试 autoloading PHP 的特性。

• 根据业务目标将模型类设计为更高级别的接口(interface)，而不是低级别的 CRUD，从而避免繁琐的 getter 和 setter。模型方法可以返回其他模型对象实例的 PHP 哈希数组。对于简单的对象字段，您可以简单地将对象成员变量公开。