题
我想参考一下使用 include 的优缺点 文件与对象(类) 开发 PHP 应用程序时。
我知道我会受益于有一个地方可以得到这个答案......我有自己的一些意见,但我期待听到其他人的意见。
一个简单的例子:
我网站上的某些页面只能由登录用户访问。我有两个实现选项(还有其他选项,但我们将其限制为这两个)
创建一个authenticate.php 文件并将其包含在每个页面上。它保存身份验证的逻辑。
创建一个用户对象,该对象具有认证功能,在每个页面引用该对象进行认证。
编辑我希望看到某种方法来权衡一种方法与另一种方法的优点。我目前的(和薄弱的原因)如下:
包含 - 有时调用函数更简单、更短、更快 对象 - 对功能和属性进行分组,以便进行长期维护。
包括 - 编写的代码更少(没有构造函数,没有类语法),这让我觉得我很懒,但这是事实。
对象 - 强制形式化和单一的功能和创建方法。
包括 - 新手更容易上手 物体 - 对新手来说较难,但专业人士却不屑一顾。
我在项目开始时会考虑这些因素,以决定是否要包含或对象。这些是我脑海中的一些优点和缺点。
解决方案
这些并不是真正相反的选择。无论如何,您都必须包含检查代码。我将你的问题理解为过程编程与程序编程。面向对象编程。
PHP3 或 PHP4 的做法是编写几行代码或一个函数,并将其包含在页眉中。这很简单,而且有效(这就是我们在 奥斯商务, ,例如电子商务 PHP 应用程序)。
但正如许多开发人员所证实的那样,维护和修改并不容易。
在 PHP5 中,您将编写一个用户对象,该对象将携带自己的数据和方法进行身份验证。您的代码将更加清晰且更易于维护,因为与用户和身份验证有关的所有内容都将集中在一个地方。
其他提示
虽然这个问题涉及几个非常有争议的问题(OOP、用户身份验证),但我将跳过这些问题并附上 Konrad 关于 __autoload 的评论。任何了解 C/C++ 的人都知道包含文件有多么痛苦。使用自动加载(PHP5 的附加功能),如果您选择使用 OOP(我几乎完全这样做),您只需要使用一些标准文件命名约定,并且(我建议)限制每个文件一个类,PHP 将为您完成其余的工作。清理代码,您不再需要担心记住删除不再需要的包含(包含的许多问题之一)。
我没有太多 PHP 经验,尽管我在当前的工作中使用它。一般来说,我发现较大的系统受益于面向对象提供的可读性和可理解性。但是一致性(不要混合面向对象和非面向对象)和您的个人偏好(尽管仅在个人项目上)也很重要。
我学会了永远不要使用 include
除了我使用的核心库和一个中央库之外 include
应用程序中这些库(+配置)的。其他一切都由全局处理 __autoload
可以配置为识别所需的不同类的处理程序。使用适当的类命名约定可以轻松完成此操作。
这不仅灵活而且非常高效并且保持架构干净。
你能说得更具体一点吗?对于您给出的示例,您需要以两种方式使用 include 。在情况 1 中,您仅包含一个文件,在情况 2 中,您需要包含类文件(例如 user.class.php)以允许 User 类的实例化。
这取决于应用程序的其余部分是如何构建的,是面向对象的吗?使用面向对象。
无论您是在课堂上还是以更程序化的方式进行,您只需检查以确保:
- 有一个会话;
- 该会话有效;和,
- 拥有会话的用户拥有适当的权限。
您可以将所有三个步骤封装到一个函数中(或者 Session 类中的静态方法也可能有效)。尝试这个:
class Session
{
const GUEST = 0;
const SUBSCRIBER = 1;
const ADMINISTRATOR = 2;
public static function Type()
{
session_start();
// Depending on how you use sessions on
// your site, you might just check for the
// existence of PHPSESSID. If you track
// every visitor with sessions, however, you
// might want to assign some separate unique
// number (that you can track in a DB) to
// authenticated sessions
if(!$_SESSION['uniqid'])
{
return Session::GUEST;
}
else
{
// For the best security, don't store the
// user's access permissions in the $_SESSION,
// but rather check against the DB. This will
// ensure that recently deleted or downgraded
// administrators will not be able to make use
// of a previous session.
return THE_ACCESS_LEVEL_ACCORDING_TO_THE_DB
}
}
}
// In your files that need to check for authentication (you
// could also do this in a controller if you're going MVC
if(!(Session::Type() == Session::ADMINISTRATOR))
{
// Redirect them to wherever you want them to go instead,
// like a log in page or something like that.
}