Вопрос

Я хотел бы получить ссылку на плюсы и минусы использования include файлы против объектов (классов) при разработке PHP-приложений.

Я знаю, что мне было бы полезно иметь одно место, где можно найти этот ответ... У меня есть несколько собственных мнений, но я с нетерпением жду возможности услышать другие.

Простой пример:

Некоторые страницы моего сайта доступны только авторизованным пользователям.У меня есть два варианта реализации (есть и другие, но давайте ограничимся этими двумя)

  1. Создайте файл Authenticate.php и включите его на каждую страницу.Он содержит логику аутентификации.

  2. Создайте объект пользователя, который имеет функцию аутентификации, ссылайтесь на объект для аутентификации на каждой странице.

РедактироватьЯ хотел бы увидеть какой-то способ взвесить преимущества одного над другим.Мои текущие (и слабые причины) следующие:

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

Включает - Меньше кода для написания (нет конструктора, нет синтаксиса классов). Назовите меня ленивым, но это правда.

Объекты - Принудительная формальность и единый подход к функциям и созданию.

Включает - Легче для новичка справляться с предметами - труднее для новичков, но оказанные профессионалами.

Я смотрю на эти факторы в начале проекта, чтобы решить, хочу ли я использовать включения или объекты.Это несколько плюсов и минусов, которые пришли мне на ум.

Это было полезно?

Решение

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

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

Но его нелегко поддерживать и модифицировать, что могут подтвердить многие разработчики.

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

Другие советы

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

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

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

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

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

Это зависит от того, как построена остальная часть приложения. Это объектно-ориентированный подход?Используйте ОО.

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

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

Вы можете инкапсулировать все три шага в одну функцию (или может работать статический метод в классе 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.
}
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top