如何在不使用框架的情况下编写好的PHP代码?

除了标准的面向对象的概念之外,当框架没有被使用时,还有哪些其他策略可以产生良好的,干净的PHP代码?

请记住:MVC,OOP和层是devise概念,而不是语言结构,也不是文件结构。

对我而言,这意味着当不使用框架,并且没有不同的编程和devise团队时, 在PHP之上使用另一个模板系统(这是一种模板语言)没有任何价值。 另外,从布局中分离代码并不一定意味着在不同的文件上执行代码。

这是我用来做一次性,很less扩展PHP Web应用程序的方式:

  1. 写一个“通用工具”文件,在那里我放置一些格式化/清理function,以及一些数据库访问function:
    1. getquery():给定一个SQL,返回一个结果对象
      • getrecord():给定一个SQL,返回一个logging对象(并closures查询)
      • getdatum():给定一个SQL,返回一个字段(并closures查询)
      • 将所有configuration(DB访问,一些URL前缀等)放在'config.php'文件中
      • 编写一个模型图层,可以是一个文件,也可以是每个存储在数据库上的对象。 在那里,将会有所有的SQL常量,基于你的概念对象,而不是数据库logging,呈现更高级别的API。

那就是你的“框架”,然后你写下“presentation”层:

  1. 每个页面有一个PHP文件,首先用一些简单的代码来获取所需的对象,接着是带有交错PHP代码的HTML,以便“填充空洞”。 除了极less数例外,那里最复杂的代码应该是for循环。 我做一个规则只使用一行, ?>应该和开头的<?php在同一行

    • 每个数据input表格都应该指向一个没有任何HTML的小型PHP,只需获取POST数据,进入数据库,然后转发到调用页面。

就是这样。 如果单独工作,它可以完成所有您需要的意图分离,而不会淹没在单个用户操作的大量文件中。 用户看到的每个页面都由一个PHP文件pipe理。

在几个月后,不用查看代码就可以很容易地进行维护,因为testing应用程序很容易,并且注意到浏览器的URL字段中的文件名。 这将直接引导您到相关的代码。

(现在,当然,我几乎所有的东西都使用Django …)

如果你发现自己混合HTML和代码,只是停止。 你是,呃… 你做错了! http://dennisjudd.com/albums/cute_cats/wrong_mike.jpg

我会说几乎相同的任何其他语言:

  • 不要过早优化
  • 保持方法小
  • 练习干
  • 练习数据驱动的编程
  • 使用明智的捷径(例如三元运算符)
  • 格式化您的代码,以便其他人能够理解
  • 不要盲目使用OO
  • 总是检查返回代码是否有错误
  • 启用最高的警告级别,并确保您的代码不会产生任何警告
  • 在input问题时要非常小心(这适用于所有弱types的语言)。 '==='操作符是你的朋友。

真的,这个问题是相当的语言不可知论,因为它适用于大多数语言,你select“滚动你自己的”。 我会做的两个build议是:

首先,仅仅因为你没有使用框架,并不意味着你不能采用分离代码的模式。 在安排源代码时,MVC模式是最低要考虑的 – 即使应用程序没有完全遵循与框架相关的路由过程,代码“ “与”代表“事物分离的东西是非常有益的。

其次,仅仅因为你select不使用完整的框架,并不意味着你需要重新发明轮子。 合理利用预包装库来解决特定的问题。 两个很好的例子是一个日志框架(log4php)和一个前端渲染/模板解决scheme(Smarty)。

尽可能远离全局:–D

如果你确实遵循面向对象的概念,比如分离关注点,你的代码将会非常好,但是这里有几点build议:

  • 框架与否,使用MVC。
  • 我不能强调,不要将自己的逻辑和你的HTML混合在一起是多么的重要。 在一个HTML文件中,PHP应该只被用作模板语言,仅此而已。
  • 使用DBAL。
  • 将您的devise与您的内容分开。 一个常用的方法是大量使用CSS,并且包含大量站点布局的页眉和页脚文件。
  • 为选项常量提供单个文件,如数据库凭证,FTP凭证等

确保遵循标准的分离问题的做法。 这意味着什么是尽量不要混淆你的业务和数据层与你的用户界面。

即使如果你不使用框架,使用模板引擎。 通过使用模板,您将分开您的应用程序的逻辑和演示文稿。 然后,devise,编码和格式化逻辑部分,就像您使用其他语言所做的一样。 使“devise师”devise的用户界面:)

面向对象并不是绝对必要的:也可以用PHP <5编写好的代码。 良好的程序代码,通过“逻辑距离”很好地分成文件和目录,也应该保证你的安全。 不过,请注意,这远远超过了OO。

最好的事情是保持一致:我见过一个项目,Smarty在大多数页面中使用,除了一个 – 最复杂的是数字。

利用PHP的内置扩展 – 例如MySQLi。 随着这些变得越来越面向对象,对框架的要求就越来越less。

例如,我可以通过使用下面的扩展创build一个有用的TwitterApp,除了核心类之外,没有实际的框架将实例绑定在一起。

  • MySQLi for database(PDO如果您需要DAL)
  • 用于RSS / API阅读的SimpleXML
  • Smarty的模板

我可能需要为Login之类的东西做一些帮助类,但是我的一对类(DAL和TPL)被两个非常好的扩展过时了。