Хранение информации о пользователе в сеансе, используя объект против обычных переменных - PullRequest
Новая
       1

Хранение информации о пользователе в сеансе, используя объект против обычных переменных

4 голосов
/ 04 января 2011

Я нахожусь в процессе внедрения системы аутентификации пользователя для моего сайта.Я использую библиотеку с открытым исходным кодом, которая поддерживает пользовательскую информацию, создавая объект User и сохраняя этот объект в моей переменной php SESSION.Это лучший способ для хранения и доступа к этой информации?

Мне немного неудобно обращаться к пользовательским переменным, потому что мне сначала нужно создать объект для доступа к ним: 

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

вместо того, чтобы просто обращаться к идентификатору пользователя, как это, как я обычно храню идентификатор пользователя: 

$_SESSION['userId'];

Есть ли преимущество в сохранении группы пользовательских данных в виде объекта вместо простого храненияих как отдельные переменные SESSION?

ps - Библиотека, похоже, также хранит несколько переменных внутри объекта пользователя (идентификатор, имя пользователя, дата присоединения, электронная почта, запрос базы данных последнего пользователя), но я действительноне хочу хранить всю эту информацию в моем сеансе.Я только хочу сохранить идентификатор пользователя и имя пользователя.

Ответы [ 2 ]

3 голосов
/ 04 января 2011

Почему бы вам не создать класс-оболочку сеанса, который обрабатывает доступ и хранение данных? Это приведет к гораздо более чистому коду и абстракции, поэтому внесение изменений в методы хранения в будущем будет довольно простым.

Вот пример оболочки: 

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;

Производит намного чище код и больше проблем.

По прошествии времени вы можете просто создать новый драйвер для хранения в базе данных, а затем просто сменить драйвер с собственного на базу данных.

Примечание: хранение объектов в базе данных может быть немного ошибочным, особенно если ваш код не организован как загрузка сеанса до того, как пользовательский класс находится в области видимости, тогда вы можете получить частичные объекты в сеансе, что приведет к отсутствию функциональности.

3 голосов
/ 04 января 2011

Я думаю, что логически группировать связанные данные вместе под одним ключом лучше всего, это объединяет соответствующие данные с общим родителем, это также дает вам больше возможностей для маневра в отношении названий ключей, так что вы можете иметь $_SESSION['user']->id против $_SESSION['user_id'], позволяет вам иметь имя свойства context , поэтому вам не нужно указывать контекст в имени ключа, как если бы вы использовали user_* key

. Я также думаю, чтоздесь используется более масштабная концепция, когда вы используете user_*, вы в значительной степени говорите, что что-либо с именем ключа user_* будет связано с пользователем.Это не хороший способ организации объектов IMO.Однако, когда вы используете клавишу user и вставляете все ассоциированные данные под , так сказать, вы получаете более чистый верхний уровень и реальную вложенную иерархию данных, а не линейную.

...