最佳实践/信息：编写PHP4 ORM

由于许多原因（基本上，所有这些都可以归结为糟糕的管理决策），我们无法切换到PHP5，这意味着我们可能还要支持PHP4几年

由于我们的许多应用程序（和许多web应用程序一样）都是被美化的CRUD应用程序，而且因为我喜欢偶尔花点时间在家庭项目上，所以我目前正在编写一个类似ORM的小类，它将作为最基本查询（插入、更新、替换、删除等）的包装器，因为它必须支持PHP4，

PDO

是不可能的，所以我必须回到特定于语言的函数，比如

mysql\u query

。因为我们使用了一些不同的系统，在不同的版本（Interbase版本4及以上，Firebird，MySQL）中，我的ORM/Wrapper类（不知道如何称呼它）肯定会变得越来越大

为了解决这个问题，我想到了两种可能的“解决方案”：

• 基于定义所用语言/RDBMS的

  $database\u system

  变量，编写一个大型类，在函数中使用

  switch

  语句
• 为每个RDBMS编写一个基类，并编写一个派生类（可能是每个版本，如果它们之间的特性差异很大）

目前我倾向于第二种选择；在我看来，它使维护变得更容易，尤其是在支持列表中添加新的RDBMS时。另一方面，由于每个RDBMS都使用自己的PHP函数集，我不确定从基类继承多少。请记住，这个类最终将支持诸如排队、一次执行（并可能提交，如果支持的话）整个查询列表等功能

---

在这种情况下，哪种方法最好？A还是B，或者有可能是我没有考虑过的C？现有类的一些示例将是完美的，不幸的是，我遇到的大多数ORM都依赖于（仅限PHP5）

PDO

类。

一定要选择2。您的OO方法优于大规模switch语句。基类将为您提供的不仅仅是继承通用方法。它为您提供了一个一致的接口，稍后当您迁移到其他一些数据库持久性策略时（当管理达到目的时，PHP5/PDO？），该接口可以用作适配器。我甚至会在PDO之后对您的接口进行严密的建模，如果需要的话，PDO甚至可以作为您自己开发的持久性层的替代品。此外，如果新开发人员已经有PDO的经验，那么他们在项目学习持久化层的学习曲线会更低。

当然要选择2。您的OO方法优于大规模switch语句。基类将为您提供的不仅仅是继承通用方法。它为您提供了一个一致的接口，稍后当您迁移到其他一些数据库持久性策略时（当管理达到目的时，PHP5/PDO？），该接口可以用作适配器。我甚至会在PDO之后对您的接口进行严密的建模，如果需要的话，PDO甚至可以作为您自己开发的持久性层的替代品。此外，如果新开发人员已经有PDO经验，那么他们在项目学习您的持久性层的学习曲线将更低。

我无法理解管理层决定使用绝对不受支持的软件作为新软件开发的基础。对于管理者来说，至少并行安装PHP5的成本几乎为零。PHP4的唯一后果是开发成本更高（PHP5类比PHP4类多，现在所有工具都主要依赖PHP5，PHP4的最后提醒也消失了），PHP5的生产成本更低——您必须自己在PHP运行时修复bug，PHP5.3使用的系统资源更少，…）

但是，如果您真的想这样做：应该做您需要的事情，并且PHP4兼容并且非常稳定

---

但我宁愿换工作。。。这样的决定通常不是唯一愚蠢的决定。

我无法理解管理层决定使用完全不受支持的软件作为新软件开发的基础。对于管理者来说，至少并行安装PHP5的成本几乎为零。PHP4的唯一后果是开发成本更高（PHP5类比PHP4类多，现在所有工具都主要依赖PHP5，PHP4的最后提醒也消失了），PHP5的生产成本更低——您必须自己在PHP运行时修复bug，PHP5.3使用的系统资源更少，…）

但是，如果您真的想这样做：应该做您需要的事情，并且PHP4兼容并且非常稳定

---

但我宁愿换工作。。。这样的决定通常不是唯一愚蠢的决定。

如果有人在寻找类似的东西（我不希望如此），但是如果-你应该看看xPDO

它是pdo在php4上工作的替代方案。 从未尝试过使用它-但我认为它应该有效。。。

---

如果有人在寻找类似的东西（我不希望如此），但是如果-你应该看看xPDO

它是pdo在php4上工作的替代方案。 从未尝试过使用它-但我认为它应该有效。。。

---

例如，我们有一些客户机在他们自己的服务器上运行我们的软件。他们希望自己的版本保持最新，但拒绝更新服务器。合同签订时，这是完全可以接受的。这是我提到的“糟糕的决定”之一，所以它并不像我说的那么糟糕。但有时也很麻烦。虽然MDB2包看起来很可靠，但我一定要检查一下。谢谢我只是对PHP5，尤其是5.3有强烈的看法，你应该试着说服你的客户：-）如果你同时启动一个PHP5版本，它会更快/更好，你可能会对你顽固的客户有更具说服力的理由