To require_once () или Not To require_once () - PullRequest
2 голосов
/ 15 июня 2011

Я строю PHP CMS с нуля.В моей системе есть один файл super-core, который в настоящее время автоматически импортирует все другие пакеты и классы, составляющие ядро ​​системы.На типичной странице используются только некоторые из этих классов и методов.

Учитывая нагрузку, которую require_once() создает на сервере для включения всех этих файлов, а также время, которое пользователь должен ждать, пока страницазагрузка, мне интересно, какой путь я должен выбрать:

  1. Сохраните супер-ядро как есть и автоматически включите все ядро ​​системы для каждой страницы, содержащей этот файл ядра.
  2. Используйте супер-ядро, чтобы включить только необходимые пакеты, такие как управление базой данных, и импортируйте дополнительные пакеты / классы по мере необходимости.

Может кто-нибудь, пожалуйста, дайте мне знать, какой из двух вариантовсамые лучшие, а также краткий обзор его плюсов и минусов?

Спасибо за потраченное время !!!

Ответы [ 3 ]

6 голосов
/ 15 июня 2011

Вы задаете вопрос о том, какая стратегия загрузки является лучшей.Это часто обсуждается в отношении автопогрузчиков .

Как и в любой стратегии, есть свои плюсы и минусы.Включение всех файлов может избавить вас от необходимости забыть один.Автозагрузчик на другом также не забывает файл.

Однако вы не всегда должны использовать ту или иную стратегию, но если вы реализуете несколько, вы можете выбирать по мере необходимости.Например, если вы разрабатываете свою CMS, вещи могут часто меняться.Но если CMS установлен на сервере, эта версия меняется не часто.

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

Для простого способа создания собственных систем я могу предложить автозагрузчик.Если вы выстроите свои классы файл за файлом, они будут автоматически загружены в тот момент, когда вы используете класс.

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

3 голосов
/ 15 июня 2011

Ранее в этом году я столкнулся с именно этой проблемой при разработке фреймворка на PHP.

Я рассмотрел плюсы и минусы и вот моя оценка:

Вариант 1 - скрипт Front Controller Patternвключить все остальные сценарии

Преимущества

  • Включение пакетов выполняется в рамках одного сценария;вы можете увидеть, какие файлы включены, а какие нет.
  • Включение определенного пакета всегда вызывается один раз, никаких накладных расходов нет.

Недостатки

  • Рассмотрим случай такого:

У нас есть два класса Rectangle и Shape.Rectangle является дочерним классом, т.е. расширением Shape.Однако основной скрипт включает классы в алфавитном порядке.Таким образом, если включено Rectangle, Shape не найдено и PHP выдаст ошибку.

Rectangle class:

class Rectangle extends Shape{

}

Shape class:

class Shape{

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

Вариант 2. Загрузка основных пакетов, а затем загрузка других пакетов по мере необходимости

Преимущества

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

Недостатки

  • Накладные расходы, так как может возникнуть несколько запросов для определенного пакета.
  • Включение пакета производится в каждый отдельный файл.

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

2 голосов
/ 15 июня 2011

Не загружайте то, что вы не собираетесь использовать. Реализуйте автозагрузчик или углубите ваши require_once.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...