Подход динамического php включает в устаревшие проекты без фронт-контроллера

Управление зависимостями через Includes /require_onces в php это боль. Время от времени я меняю вещи и разбиваю вещи, и мне приходится переосмысливать свой подход к инициализации самого первого include () / require () в php. Я чувствую, что мне не хватает более надежной техники, которая бы работала и решала все мои проблемы, но я просто пока не нашел ее.

Автозагрузка с помощью mvc была бы хороша! Но для устаревших процедурных проектов я не думаю, что это помощь?

Прошлые подходы

Наверное, как и все, я начал с относительного пути. require_once('../../../core/core.php'); например. К сожалению, это ломается, когда вы начинаете требовать библиотек, которые имеют свои собственные необходимые зависимости. Итак, я перешел к использованию динамического включения, которое анализирует основную папку проекта из любого места в иерархии: require_once(substr(dirname(__FILE__), 0, strpos(dirname(__FILE__), 'my_project')+8).'core/database/admin.database.connection.php'); это означало, что я мог бы пропустить это где угодно, где это уместно, и переместить его — куда угодно — в проект, и он все равно будет работать! К сожалению, это сломалось, когда я реализовал CI, и проект CI установил корень проекта как: /home/rof/bitbucket.org/repo_name/clone/ который не включал определенную строку «my_project» и таким образом нарушил все включения. Так что в течение последнего часа или около того я исправляю включает, и это не весело. Я хочу найти «окончательное решение».

В настоящее время использую

В настоящее время я изменяю включает в себя:

require_once(realpath(__DIR__.'/../../').'/core/database/admin.database.connection.php');

К сожалению, если я переместлю группу скриптов вверх или вниз по каталогу (например, переместим пользователей / orders / в admin / orders или все различные подходы к ведению домашнего хозяйства), для этого потребуется снова переписать каждый отдельный скрипт. Изменение DIR.’/../../’ к DIR.’/../../../’ или что-то еще. Это отстой, потому что это настолько сложно, что страшно пытаться переписать проект или каталог в целом, что-то, возможно, просто сломается.

Мои цели

• 1-я простота, я хочу установить включения и быть уверенным, что они будут
  Работа & забудь о них.
• 2-х уровневая система, так что разные области
  может включать библиотеки с разными уровнями доступа
• 3-е я не хочу переписывать включает, когда все меняется. В идеале я бы с удовольствием
  написать включает в одном месте для доступа администратора, одно место для пользователя
  доступ и одно место для публичного доступа.

Каково окончательное решение для не объектно-ориентированных, процедурных / функциональных php-проектов со сложной структурой каталогов?

Пример структуры каталогов & Сценарии

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

core/
- core.php
- environment.php
- database/
- database.php
- admin.database.connection.php
- user.database.connection.php
- public.database.connection.php
www/
- index.php
- contactus.php
- map.php
- ...
- users/
- login.php
- logout.php
- accountdetails.php
- ...
- admin/
- login.php
- logout.php
- index.php
- admin.php
...
- reports/
- revenue_report.php
- orders.php
- clientslist.php
- orders/
- orderslist.php
- orderview.php
...

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