Вопрос
Я хотел бы получить ссылку на плюсы и минусы использования include файлы против объектов (классов) при разработке PHP-приложений.
Я знаю, что мне было бы полезно иметь одно место, где можно найти этот ответ... У меня есть несколько собственных мнений, но я с нетерпением жду возможности услышать другие.
Простой пример:
Некоторые страницы моего сайта доступны только авторизованным пользователям.У меня есть два варианта реализации (есть и другие, но давайте ограничимся этими двумя)
Создайте файл Authenticate.php и включите его на каждую страницу.Он содержит логику аутентификации.
Создайте объект пользователя, который имеет функцию аутентификации, ссылайтесь на объект для аутентификации на каждой странице.
РедактироватьЯ хотел бы увидеть какой-то способ взвесить преимущества одного над другим.Мои текущие (и слабые причины) следующие:
Включает в себя - иногда функция просто проще/короче/быстрее для вызова объектов - группировка функциональности и свойства, которые приводит к долгосрочному обслуживанию.
Включает - Меньше кода для написания (нет конструктора, нет синтаксиса классов). Назовите меня ленивым, но это правда.
Объекты - Принудительная формальность и единый подход к функциям и созданию.
Включает - Легче для новичка справляться с предметами - труднее для новичков, но оказанные профессионалами.
Я смотрю на эти факторы в начале проекта, чтобы решить, хочу ли я использовать включения или объекты.Это несколько плюсов и минусов, которые пришли мне на ум.
Решение
Это не совсем противоположные варианты.В любом случае вам придется включить проверочный код.Я прочитал ваш вопрос как процедурное программирование против.ОО-программирование.
Написание нескольких строк кода или функции и включение их в заголовок страницы — вот как это делалось в PHP3 или PHP4.Это просто, это работает (так мы сделали в osCommerce, например, PHP-приложение для электронной коммерции).
Но его нелегко поддерживать и модифицировать, что могут подтвердить многие разработчики.
В PHP5 вы должны написать объект пользователя, который будет содержать свои собственные данные и методы аутентификации.Ваш код станет более понятным и простым в обслуживании, поскольку все, что связано с пользователями и аутентификацией, будет сосредоточено в одном месте.
Другие советы
Хотя вопрос затрагивает пару очень спорных вопросов (ООП, аутентификация пользователя), я пропущу эти и второй комментарий Конрада о __autoload.Любой, кто знает C/C++, знает, насколько сложной может быть работа с файлами.Благодаря автозагрузке, дополнению PHP5, если вы решите использовать ООП (что я делаю почти исключительно), вам нужно всего лишь использовать некоторые стандартные соглашения об именах файлов и (я бы рекомендовал) ограничить один класс для каждого файла, а PHP сделает все остальное за вас.Очищает код, и вам больше не придется беспокоиться о том, чтобы не забыть удалить включения, которые больше не нужны (одна из многих проблем с включениями).
У меня нет большого опыта работы с PHP, хотя я использую его на своей нынешней работе.В целом я считаю, что более крупные системы выигрывают от читаемости и понятности, которые обеспечивает объектно-ориентированный подход.Но такие вещи, как последовательность (не смешивайте объектно-ориентированное и не-ориентированное) и ваши личные предпочтения (хотя на самом деле только в личных проектах) также важны.
Я научился никогда не использовать include
в PHP, за исключением основных библиотек, которые я использую, и одной центральной 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.
}