mysqli:混合OO和程序代码

时间:2015-06-29 14:06:55

标签: php mysqli

php manual mysqli page讨论了混合面向对象和程序样式,并说为了代码清晰度和编码风格的原因,不推荐混合使用这两种样式。"

我维护并更新了一个大约10年前的大型项目(成千上万的代码行),至少会继续这么多。 (如果你愿意的话,把它看成是一种图像CMS。)所有现有的mysqli代码都是程序化的,大部分都是从最初使用的旧的mysql扩展中改变的。 (并且在大多数情况下仍然可以完美地运行。)项目代码模块可以根据需要进行更新,添加,删除和/或替换,因此我将在该项目上进行多年的零星工作。 / p>

为了清晰,简洁和可维护性,我想将其切换为OO样式。与从mysql到mysqli的变化不同,只需要一点点思考和大量全局搜索/替换就不会轻易完成。一次改变整个项目并不是一个有吸引力的选择。简单地与程序性的mysqli一起生活可能是最节省时间的,但是我不介意把工作放在更好的地方,只要我不做所有这一切马上。

仅更改项目的一部分是否切实可行,将其他部分保留为程序样式,直到它们重新写入为止?

这里有什么问题?什么东西可以自由混合,什么东西不能组合OO和程序mysqli?

编辑:为了清楚起见,我并没有问到广泛的风格问题,纯粹是为了将OO风格和程序风格调用混合到mysqli扩展中。除了一个平淡无奇的声明之外,该手册不包含任何内容,并且可以随时在样式之间切换。没有提供任何有用的细节。

1 个答案:

答案 0 :(得分:2)

混合OO和过程样式没有错。正如引文所说,“出于代码清晰和编码风格的原因,不建议这样做。”

但是,如果您从mysql_*迁移到mysqli_*时所做的只是全局搜索,而只是为了更改函数名称而进行替换,那么您真的错过了新API的全部重点。

这个想法是,在进行迁移时,您应该实现准备好的语句并清除mysql_*函数通常是罪魁祸首的混乱的意大利面条代码。坚持程序风格完全没有好处,甚至使代码更加复杂。当以OO样式使用时,准备好的语句和异常要干净得多。

如果不使用参数绑定和mysqli异常,则最好坚持使用mysql_*函数。