【问题标题】:Storing user info in a session using an object vs. normal variables使用对象与普通变量在会话中存储用户信息
【发布时间】:2011-06-03 03:57:29
【问题描述】:

我正在为我的网站实施用户身份验证系统。我正在使用一个开源库,它通过创建一个用户对象并将该对象存储在我的 php SESSION 变量中来维护用户信息。这是存储和访问该信息的最佳方式吗?

我发现访问用户变量有点麻烦,因为我必须先创建一个对象才能访问它们:

$userObj = $_SESSION['userObject'];
$userObj->userId;

我通常不会像这样访问用户 ID:

$_SESSION['userId'];

将一堆用户数据存储为一个对象而不是将它们存储为单独的 SESSION 变量是否有优势?

ps - 该库似乎还在用户对象中存储了一些变量(id、用户名、加入日期、电子邮件、最后一个用户数据库查询),但我真的不关心将所有这些信息存储在我的会话中.我只想保留用户 ID 和用户名。

【问题讨论】:

  • 如果你想停止使用你的库,也许你会在这个单独的操作上节省一行代码,但从长远来看你可能会失去更多
  • 好吧,我不会停止使用该库,我可能只是修改我想要更改的部分。我还应该澄清一下,我一般只是对在 Session 变量中存储对象感到好奇。我读到我应该保持会话变量轻,所以我想听听其他人会说什么。
  • 不应该是$userObj =& $_SESSION['userObject'];
  • 应该吗?我从来没有真正使用过很多引用,但我认为这是有道理的。太棒了!我正在学习:D
  • 这需要作为参考吗?既然是对象,默认不就是引用吗?

标签: php session authentication object


【解决方案1】:

为什么不创建一个会话包装类来处理数据的访问和存储?这将产生更简洁的代码和抽象,因此对存储方法的更改非常容易。

这是一个包装器的例子:

abstract class Session
{
     private static $_started = false;
     private static $_driver;

     public static function start($driver = "native", $site = "default")
     {
         if(self::$_started === false)
         {
             require_once "drivers/" . $driver . ".php";
             self::$_driver = new $driver($_site);
         }
     }

     public static function set($key,$value)
     {
          self::$_driver->set($key,$value);
     }

     public static function get($key)
     {
          self::$_driver->get($key);
     }

     public static function remove($key)
     {
          self::$_driver->remove($key);
     }
}

以上只是简单的,但您应该明白了,您还必须创建具有所需方法集的本机驱动程序文件,并且它们应该相应地存储会话数据。

像这样使用 Session 类的示例:

Session::start("native");

    /*
        * Generic Code
    */

Session::set("key","value (:");

在获取“用户”对象时,您可以这样做:

Session::get("userObj")->id;

产生更简洁的代码和更大范围的问题。

随着时间的推移,您可以创建一个新的驱动程序存储在数据库中,然后将您的驱动程序从本地更改为数据库。

注意:在数据库中存储对象可能会有点问题,特别是如果您的代码没有组织为在用户类处于作用域之前加载会话,那么您可以在会话中获取部分对象,这将导致功能不足。

【讨论】:

  • 正确的包含顺序非常重要,因为如果你弄错了,事情就会以奇怪的方式中断。
  • 是的,我不得不多次就这个问题提出建议,我更喜欢在每个请求中只存储 ID 并从数据库中提取用户,这样更改永远不会延迟到新的会话开始.
【解决方案2】:

我认为将相关数据按逻辑分组到一个键下是最好的,它将相关数据与一个共同的父级耦合,它还为您提供了更多关于键名的回旋余地,因此您可以使用 $_SESSION['user']->id 而不是 @ 987654322@,允许您拥有属性名称​​context,因此您不必像使用user_* 键那样在键名中提供上下文

我还认为这里有一个更大的概念,当您使用user_* 时,您几乎是在说任何具有键名user_* 的东西都将与用户相关联。这不是组织对象 IMO 的好方法。但是,当您使用user 键并将所有关联数据粘贴在它的下方 可以这么说时,您将拥有更清晰的顶层和真正的嵌套数据层次结构,而不是线性数据层次结构.

【讨论】:

  • 那么库的做法,将一个对象内的所有用户数据分组到一个会话密钥中,您认为是正确的方法吗?
  • @justini 是的,我完全同意这种方法。
猜你喜欢
  • 1970-01-01
  • 2012-12-01
  • 2011-01-03
  • 1970-01-01
  • 2015-12-14
  • 2017-05-24
  • 1970-01-01
  • 1970-01-01
  • 2017-08-07
相关资源
最近更新 更多