Есть опыт разработки на MVC фраймворках, таких как Yii, Zend. Встала задача доработки уже существующей площадки, разработанной по PAC принципу. Переписать весь имеющийся функционал вполне реально, но владельцы упираются в производительность веб-приложения и не особо верят представленным тестам.
В свою же очередь не вижу особой возможности расширения функционала при текущей ситуации, а так же скорость разработки будет значительно ниже.
Если есть особо критические моменты PAC подхода, которые не дают масштабировать приложения, то буду рад услышать, если же особых недостатков нет, то будем пробовать погружаться и проникаться.
Если мне память не иземняет, PAC является развитием идей MVC. По сути это очень похожая штука на HMVC. В этом ключе PAC выгоднее в контексте масштабирования чем простое MVC. Другой вопрос как это у вас реализовано.
в данный момент там каша, но в целом имеется:
1. Один базовый абстрактный класс от которого наследуются классы разделов
2. Папка с шаблонами под каждый раздел, а так же некоторые общие элементы
3. Отдельный общий класс для работы с БД, притом он судя по стилю кода откуда-то скопирован.
4. Отдельный класс для работы с шаблонами.
5. Класс, который отвечает за авторизацию пользователя, со всеми плюшками вроде доступа с определенного ip
6. Отдельный класс логирования действий пользователя
Часть базовых вещей, авторизация, утилиты, пути к папкам шаблонов собираются в index.php, после успешной авторизации все работает через базовый слой, в который синглтонами подключены вспомогательные классы (логирование, работа с БД, работа с шаблонами), и который в зависимости от роута подключает нужный класс раздела и вызывает метод отрисовки базовой страницы. Далее при работы в зависимости от запроса вызывается требуемый метод из данного класса.
В целом все бы ничего, но самый хаос творится в этих самых классах разделов: тут и бизнес логика и запросы в БД, и получение шаблона в переменную, а затем замена с помощью str_replace переменных на данный из запроса, ну и возврат этой переменной со всем шаблоном для отрисовки.
Но и если бы это еще все работало стабильно, дак нет же, наблюдаются непонятные глюки с авторизацией пользователей, то есть "само собой" один пользователь может стать залогиненным под другим. Особых закономерностей этого действия выявить не удалось, но замечено чем дольше пользователь залогинен, тем вероятнее что его переключит на другого. Опять же возможно это из-за синглон объектов...
так у вас просто говнокод, причем тут MVC vs PAC? Вам в любом случае нужно закладывать время на рефакторинг, покрывать все тестами, развязывать систему....
@Fesor вот это скорее и есть основная проблема, на мой взгляд написать заново на фраймворке с которым уже работал будет гораздо быстрее, нежели рефакторить то что там написано. Хотя про сам подход тоже интересно +/-
@Playbot PAC это тот же HMVC только с несколько другой терминологией. Можно норм делать вещи на нем. MVC (если брать обычный, без иерархии и т.д.) будет менее гибок.
Что до "переписать с нуля" - это конечно можно, если проект не сильно большой и можно будет уложиться в месяца 4-6. Но если проект уже крутится в продакшене или должен быть там скоро - лучше рефакторить этот.
У меня как-то был опыт рефакторинга проекта с применением Symfony/HttpKernel + stack php + silex (можно заменить любым фреймворком имплементящим HttpKernelInterface). В этом случае все новые штуки можно писать уже на норм фреймворке, а старые потихоньку по мере продвижения в код рефакторить. Систему авторизации можно сразу запихнуть в мидлвар как надстройка над приложением. Можно взять текущую API который использует старый движек и сделать там биндинг к компонентам фреймворка или вашим нормальным... Вариантов на самом деле масса.
Чисто теоритически при таком подходе риски будут ниже чем при "написать с нуля". так как у вас код стабилизируется на месяц два раньше.
Ну и да, без тестов вообще лучше ничего не трогать. Покройте хотя бы behat-тестами, назовите это BDD и в путь. Но лучше нормальными функциональными (если тестов небыло вообще) а потом компоненты которые собираетесь рефакторить - юнит тестами.
Простой