Я исторически использовал монолитный подход к PHP-кодированию.
То есть, я пишу один index.php со средним размером 70k-250k и использую
mod_rewrite превратить остальные
REQUEST_URI
в параметры, переданные в index.php, чтобы контролировать происходящее.
Альтернативой было бы написать много небольших скриптов php, каждый из которых специализировался с определенной целью. Я думаю, что некоторые из моих более активных сценариев ajax могут извлечь из этого выгоду.
Одна вещь, которая удержала меня в этом процессе мысли, – я не знаю, как включает в себя использование, особенно условные включения, влияющие на производительность кэша операций операций.
Обычно я избегаю, если это возможно, из-за моей паранойи, но это приводит либо к дублированию кода, либо к тому, чтобы оставаться монолитным.
Так как я использую mod_rewrite, конвертация между двумя методологиями должна быть простой.
Я с нетерпением жду ваших комментариев.
EDIT: одно из моих целевых приложений в настоящее время обрабатывает 80-100 просмотров страниц в секунду (у меня есть приличное оборудование). Большинство из них – запросы ajax. Все работает и быстро, но я разработал как программист php без критики и нуждаюсь в нем.
Модульный код легче понять и поддерживать. Огромная монолитная кодовая база может стать как карточный домик. На практике это прекрасно работает, но изменение любого из нижних элементов становится невозможным. Если вы разделите свой код на четкие абстракции, это может быть намного проще вносить изменения, и вы сэкономите свой кошмар, если сможете добавить разработчиков.
Бонусы за производительность, не связанные с включенными файлами, намного превосходят простоту обслуживания и отладки большого приложения с использованием включенных файлов.
Переработка отходов. Копирование и вставка кода из одного приложения в другое – это адский ад.
В дополнение к другим комментариям (с которыми я полностью согласен), другое мнение: я сделал опыт того, что монолитный подход, если он доведен до крайности, стоит ценную ОЗУ – весь файл должен быть загружен для интерпретации, независимо от того, все от него необходимо или нет, и это одно поедает много от 8, 16 или 32 МБ, которые вы получаете за экземпляр.
Не забудьте про тестирование и поддержание кода. Я не могу создать изображение, если вы можете написать модульные тесты для проекта, который находится только в одном файле. Более того, трудно предсказать, какая функциональность может быть нарушена только что внесенными изменениями. В случае модульной архитектуры, если вы меняете какой-то модуль, вы можете только сломать этот модуль и модули, которые зависят от него. Даже небольшие изменения могут быть фатальными для одиночных файловых проектов (вы можете забыть закрыть цитату, которая сломает сразу все страницы). Я думаю, что вы должны повторить все функциональные возможности после небольших изменений, которые мы сделали. И это может быть болью для тестировщиков, поскольку вы не можете использовать модульные тесты.
Также, если весь код, который я сохранил в одном файле, у вас скорее будет плохой код. Такой код позволит вам использовать глобальные переменные. В этом случае трудно повторно использовать такой код в другом проекте. Вы можете скопировать его, но помните, когда вы копируете что-то, вы копируете все его ошибки. Просто придумайте проект, в котором вы можете использовать набор хорошо протестированных (скажем, благодаря модульным тестам) библиотек. Когда появляется новая ошибка, она просто фиксируется в одном месте.
Еще одна вещь, когда вы работаете в команде с использованием одного файла, будет больно. Даже если есть только 2 разработчика, они тратят много времени на слияние изменений.
В любом случае, если ваш проект невелик, вы можете использовать однопользовательский файл.