PHP включает в себя против OOP

Это не совсем противоположные варианты выбора. Вам все равно придется включить проверочный код. Я прочитал Ваш вопрос как процедурное программирование против программирования OO.

Написание нескольких строк кода или функции и включение их в заголовок страницы - Вот как это делается в PHP3 или PHP4. Это просто, это работает (так мы сделали это в osCommerce, например, в приложении eCommerce PHP).

Но это не так просто поддерживать и изменять, как могут подтвердить многие разработчики.

В PHP5 вы бы написали пользовательский объект, который будет нести свои собственные данные и методы аутентификации. Ваш код будет понятнее и проще в обслуживании, поскольку все, что связано с пользователями и аутентификацией, будет сосредоточено в одном месте.

Хотя этот вопрос затрагивает несколько очень спорных вопросов (OOP, аутентификация пользователя), я пропущу эти и второй комментарий Конрада о __autoload. Любой, кто знает C/C++, знает, как много боли может быть, включая файлы. С autoload, добавлением PHP5, если вы решите использовать OOP (что я делаю почти исключительно), вам нужно только использовать какое-то стандартное соглашение об именовании файлов и (я бы рекомендовал) ограничить один класс на файл, и PHP сделает rest за вас. Очищает код, и вам больше не нужно беспокоиться о том, чтобы помнить об удалении включений, которые больше не нужны (одна из многих проблем с включениями).

У меня нет большого опыта PHP, хотя я использую его на своей нынешней работе. В общем, я считаю, что большие системы выигрывают от читаемости и понятности, которые обеспечивает OO. Но такие вещи, как последовательность (не смешивайте OO и не OO) и ваши личные предпочтения (хотя только на самом деле в личных проектах), также важны.

Я научился никогда не использовать include в PHP, кроме как внутри основных библиотек, которые я использую, и одной центральной include из этих библиотек (+config) в приложении. Все остальное обрабатывается глобальным обработчиком __autoload , который может быть настроен для распознавания различных необходимых классов. Это можно легко сделать, используя соответствующие соглашения об именовании для классов.

Это не только гибко, но и довольно эффективно и сохраняет чистоту архитектуры.

Не могли бы вы быть немного конкретнее? Для примера, который вы приводите, вам нужно использовать include в обоих направлениях. В случае 1 вы включаете только файл, в случае 2 вам нужно включить файл класса (например user.class.php), чтобы разрешить создание экземпляра пользовательского класса.

Это зависит от того, как строится rest приложения, это OO? Используйте OO.

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

1. Есть сеанс связи;
2. Что сеанс является действительным; и,
3. Что пользователь, владеющий сеансом, имеет соответствующие привилегии.

Вы можете инкапсулировать все три шага в одну функцию (или статический метод в классе сеанса может работать). Попробовать это:

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.
}