10  /  330

Структура файлов

Просмотров: 11091 (Статистика ведётся с 06.02.2017)
Вопрос: Почему допускается хранение контента в файловой системе, пусть даже статичного? Не место ли контенту в базе данных?

Вадим Думбравану: так удобнее, причем как разрабатывать, так и управлять.

Файлы и База данных

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

Примечание: исполнение PHP это большое преимущество статической страницы Bitrix Framework.

Файлы можно править как по FTP, так и в SSH, не прибегая к дополнительным инструментам СУБД. Их легко копировать, перемещать, делать резервные копии и т.п. Строго говоря, вы можете весь контент хранить в БД. Но для простых статичных сайтов это будет явное усложнение и замедление.

Реализация на файлах кажется проблематичной в том плане, что от такой системы ожидается десятки тысяч файлов на диске. Обычно это не так. Динамическая информация (новости, каталог товаров, статьи) сохраняются в БД модулем Информационные блоки. Тогда для вывода, например, десятка тысяч товаров в интернет-магазине используется одна единственная физическая страница (файл). В этом файле вызывается компонент инфоблоков, который в свою очередь выбирает и выводит товары из базы данных.

Например, для каталога товаров действительно нужно создать папку на диске, но только одну, например, /catalog, поместить туда комплексный компонент и далее страницы товаров могут иметь вид, например: http://***.ru/catalog/1029.html Естественно, что эти адреса будут "мнимыми" и обрабатываться системой. Файлов под них в папке /catalog не создается.

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

При должном умении публичная часть может состоять из десятка физических файлов. Весь контент может быть в инфоблоках, включая меню. Но обычно статические страницы (например, О компании) удобнее редактировать как файл, а не как запись БД. Но если таких статических страниц становится неограниченно много, то это повод, чтобы структурировать их и разместить не на диске, а в инфоблоках.

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

Большое количество файлов - свойство аналогичных систем. (У ZendFramework есть такая же особенность). При правильной конфигурации хостинга эту проблему возьмут на себя прекомпиляторы php. Критичным может оказаться размер выделяемого хостером места и большое число файлов системы. (Проблемой становится не штатная работа Bitrix Framework, а, например, работа систем бэкапов у хостеров. На большом количестве файлов они начинают себя чувствовать не очень хорошо.) Поэтому для выбора хостера рекомендуем пользоваться списком рекомендуемых хостингов.

Резюме. В качестве инструмента хранения структуры сайта выбрана именно файловая система, а не база данных в силу того что:

  • Файл дает больше свободы разработчику сайта. Поскольку файл в системе - это просто исполняемый файл.
  • Так понятнее для управления. В корне такого представления - структура статических страниц HTML, разложенных по папкам. Путем некоторого совершенствования (внедряя небольшое количество PHP-кода), мы из такого сайта сразу получаем работающий на Bitrix Framework проект.
  • В какой-то мере это - традиция, которая имела большое значение на заре становления CMS.
  • Такое представление соответствует опыту контент-менеджеров, которые работают с локальными файловыми системами (папки и файлы).

Структура сайта также может быть и в БД (инфоблоки), но управлять иерархией в реляционной БД не очень-то удобно.

Рассмотрим использование файлов в Bitrix Framework на примерах:

  1. Файловая система и меню. Меню в файлах позволяет не подключать БД там, где это реально не нужно. То же самое относится к свойствам страниц и разделов, а также правам доступа к файлам. Теоретически можно собрать информационный сайт, где вообще не будет ни одного обращения к БД. Будет работать быстрее, особенно на разделяемом хостинге. Есть и бонусы: при копировании раздела сразу естественным образом копируются меню, права доступа, свойства раздела.
  2. Файловая система и пользователи. Пользователям из административного раздела открыт доступ к файлам ядра и другим программным файлам. Но пользователи бывают разные. Например, техподдержка 1С-Битрикса. Если веб-разработчик не уверен в своих пользователях, то он всегда может запретить им как редактирование кода PHP, так и целых разделов (ядра). По современной концепции Bitrix Framework в публичной части не должно быть кода PHP - все должно быть инкапсулировано в компоненты. Тогда пользователь редактирует или "голую" статику, или настраивает компонент.
  3. Файловая система и языковые версии. Было бы трудно сопровождать языковую информацию в БД. Информация в языковых файлах меняется крайне редко - проще раз в год отредактировать строчку в языковом файле, чем хранить эти статические фразы в базе. И повторимся: база данных - это медленно и избыточно.

Структура файлов

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

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

Вся система целиком лежит в каталоге /bitrix/, в него входят следующие подкаталоги и файлы:

  • /admin/ - административные скрипты;
  • /cache/ - файлы кэша;
  • /activities/ - папки действий для бизнес-процессов;
  • /components/ - папка для системных и пользовательских компонентов;
  • /gadgets/ - папки гаджетов;
  • /js/ - файлы javascript модулей;
  • /stack_cache/ - файлы кеша "с вытеснением";
  • /themes/ - темы административного раздела;
  • /wizards/ - папки мастеров;
  • /images/ - изображения используемые как системой в целом, так и отдельными модулями;
  • /managed_cache/ - управляемый кеш;
  • /modules/ - каталог с модулями системы, каждый подкаталог которого имеет свою строго определённую структуру;
  • /php_interface/ - вспомогательный служебный каталог, в него входят следующие каталоги и файлы:
    • dbconn.php - параметры соединения с базой;
    • init.php - дополнительные параметры портала;
    • after_connect.php - подключается сразу же после создания соединения с базой;
    • dbconn_error.php - подключается при ошибке в момент создания соединения с базой;
    • dbquery_error.php - подключается при ошибке в момент выполнения SQL запроса;
    • /ID сайта/init.php - дополнительные параметры сайта; файл подключается сразу же после определения специальной константы c идентификатором сайта - SITE_ID;
  • /templates/ - каталог с шаблонами сайтов и компонентов , в него входят следующие подкаталоги:
    • /.default/ - подкаталог с общими файлами, используемыми тем или иным шаблоном по умолчанию, структура данного каталога аналогична нижеописанной структуре каталога содержащего конкретный шаблон;
    • /ID шаблона сайта/ - подкаталог с шаблоном сайта, в него входят следующие подкаталоги и файлы:
      • /components/ - каталог с кастомизированными шаблонами компонентов;
      • /lang/ - языковые файлы принадлежащие как данному шаблону в целом, так и отдельным компонентам;
      • /images/ - каталог с изображениями данного шаблона;
      • /page_templates/ - каталог с шаблонами страниц и их описанием хранящимся в файле .content.php. Когда пользователь создает новую страницу, он может выбрать, по какому шаблону из представленных в этом каталоге это будет сделано;
      • header.php - пролог данного шаблона;
      • footer.php - эпилог данного шаблона;
      • template_styles.css - основной файл стилей для шаблона;
      • styles.css - CSS стили шаблона для визуального редактора (вкладка Стили сайта);
  • /tools/ - при инсталляции в этот каталог копируются дополнительные страницы, которые могут быть непосредственно использованы на любых страницах сайта: помощь, календарь, показ изображения и т.п.;
  • /updates/ - каталог, автоматически создаваемый системой обновлений;
  • header.php - стандартный файл, подключающий в свою очередь конкретный пролог текущего шаблона сайта; данный файл должен использоваться на всех страницах публичной части;
  • footer.php - стандартный файл, подключающий в свою очередь конкретный эпилог текущего шаблона сайта; данный файл должен использоваться на всех страницах публичной части;
  • license_key.php - файл с лицензионным ключом;
  • spread.php - файл используемый главным модулем для переноса куков посетителя на дополнительные домены различных сайтов;
  • redirect.php - файл используемый модулем Статистика для фиксации событий перехода по ссылке;
  • rk.php - файл по умолчанию используемый модулем Реклама для фиксации событий клика по баннеру;
  • stop_redirect.php - файл используемый модулем Статистика для выдачи какого либо сообщения посетителю, попавшему в стоп-лист;
  • activity_limit.php - файл используемый модулем Статистика для выдачи сообщения роботу при превышении им лимита активности;
  • и другие служебные файлы и папки.

В зависимости от используемой редакции некоторые каталоги и файлы могут отсутствовать.


80
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии