最佳实践/信息：编写 PHP4 ORM
由于多种原因（基本上所有这些原因都可以归结为糟糕的管理决策），我们无法切换到 PHP5，这意味着我们可能还需要支持 PHP4 几年。
由于我们的许多应用程序（与许多 Web 应用程序一样）都是美化的 CRUD 应用程序，而且因为我喜欢偶尔做一些家庭项目来浪费一些时间，所以我目前正在编写一个类似 ORM 的小型类，它将作为大多数基本查询（插入、更新、替换、删除等）的包装器。由于它必须支持 PHP4，所以 PDO 是不可能的，所以我必须回退特定于语言的函数，例如 mysql_query。因为我们使用了几个不同的系统，在不同的版本中（Interbase 版本 4 及以上版本、Firebird、MySQL），我的 ORM/Wrapper 类（不知道该怎么称呼它）必然会变大。
为了解决这个问题，我想到了两种可能的“解决方案”：
- 编写一个大型类，在函数内使用基于
$database_system变量的switch语句，该变量定义了使用的语言/RDBMS - 编写一个基类，并为每个 RDBMS 编写一个派生类（可能每个版本，如果它们之间的功能差异很大）。
目前我倾向于第二种选择；在我看来，它使维护变得更加容易，尤其是在将新的 RDBMS 添加到支持列表时。另一方面，由于每个 RDBMS 都使用自己的一组 PHP 函数，我不确定需要从基类继承多少内容。请记住，此类最终将支持诸如排队、立即执行（如果支持的话，可能还可以提交）整个查询列表等功能。
鉴于这种情况，哪种方法最好？ A 或 B，或者是否有可能是我尚未考虑的 C？现有类的一些示例将是完美的，不幸的是我遇到的大多数 ORM 都依赖于（仅限 PHP5）PDO 类。
For a number of reasons (all of which can, basically, be broken down to bad management decisions) we're unable to switch to PHP5, meaning we'll have to support PHP4 for probably a few more years.
Since a lot of our applications (as with a lot of web apps) are glorified CRUD apps, and because I like to pick up the occasional home project to waste some time on, I'm currently writing a small ORM-like class that will serve as a wrapper for most basic queries (insert, update, replace, delete, among others.) Since it has to support PHP4, PDO is out of the question, so I'll have to fall back to language-specific functions such as mysql_query. Because we're using a few different systems, in a variery of versions (Interbase versions 4 and above, Firebird, MySQL), my ORM / Wrapper class (not sure what to call it), is bound to grow big.
To tackle this problem, I've thought of two possible 'solutions':
- Write one massive class, with
switchstatements inside the functions based on a$database_systemvariable that defines the language/RDBMS used - Write one base class, and write one derived class per RDBMS (possibly per version, if the features differ a lot between them).
Currently I'm leaning towards the second option; in my view, it makes maintenance easier, especially when adding a new RDBMS to the supported list. On the other hand, with every RDBMS using it's own set of PHP functions, I'm not sure how much there would be to inherit from a base class. Keeping in mind this class will eventually support features such as queuing, executing (and possibly committing, if supported) a whole list of queries at once.
Given this situation, which approach would be best? A or B, or is there possibly a C which I didn't consider yet? Some examples of existing classes would be perfect, unfortunately most ORM's I've come across rely on the (PHP5 only) PDO class.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
绝对选择你的选项 2。你的 OO 方法优于大量的 switch 语句。您的基类将为您提供的不仅仅是继承通用方法。它为您提供了一个一致的接口，当您迁移到其他数据库持久性策略时（当管理人员意识到时，PHP5/PDO？），该接口可以用作适配器。我什至会在 PDO 之后对您的界面进行精密建模，如果需要的话，PDO 甚至可以直接替代您自己开发的持久层。此外，如果项目的新开发人员已经具有 PDO 经验，那么他们学习持久层的学习曲线将会更低。
Definitely go with your option 2. Your OO approach is superior to the massive switch statement. Your base class will give you more than just inheriting common methods. It gives you a consistent interface which can later be used as an adapter when you migrate to some other database persistence strategy (PHP5/PDO when management comes to their senses?). I would even closely model your interface after PDO to the point where PDO could even be a drop-in replacement for your homegrown persistence layer if needed. Additionally, the learning curve for new developers on the project learning your persistence layer will be lower if they already have experience with PDO.
我无法理解管理层决定使用完全不受支持的软件作为新软件开发的基础。对于管理者来说，至少并行安装 PHP 5 的成本接近于零。 PHP 4 的唯一后果是更高的开发成本（PHP 5 类比 PHP 4 更多，现在所有工具大多依赖于 PHP 5，最后关于 PHP 4 的提醒消失了）并且使用 PHP 5 进行生产更便宜 - 你有为了自己修复 PHP 运行时中的错误，PHP 5.3 使用更少的系统资源，....）
但如果你真的想这样做： Pear::MDB2 应该可以满足您的需求，并且与 PHP 4 兼容并且非常稳定。
但我宁愿换工作……这样的决定通常不是唯一愚蠢的决定。
I can't understand a management decision to use absolutely unsupported software as base for new software development. For a manager there are close to zero costs for installing PHP 5 at least in parallel. The only consequence of PHP 4 are higher development costs (there are more PHP 5 classes than for PHP 4, all tools these days mostly depend on PHP 5 and the last reminders of PHP 4 disappear) and production with PHP 5 is cheaper - you have to fix bugs in the PHP runtime yourself, PHP 5.3 uses way less system resources, ....)
But if you really want to go that way: Pear::MDB2 should do what you need and is PHP 4 compatible and very stable.
But I'd rather change jobs ... such decisions usually aren't the only stupid ones.
如果有人正在寻找类似的东西（我不希望如此），但如果 - 你应该看看 xPDO。
它是在 php4 上工作的 pdo 的替代方案。
从未尝试过使用它 - 但我认为它应该有用......
http://www.xpdo.org/
If someone is looking for something simular (I don't hope so) but if - you should take a look at xPDO.
It is an alternative for pdo working on php4.
Never tried to use it - but I think it should work ...
http://www.xpdo.org/