Как правильно задавать конфигурационные переменные для приложения на PHP?

Question

[Дмитрий]

Скажем, я пишу какое-то приложение на php (небольшой движок сайта на MVC). В программе часто используются какие-то постоянные данные, которые используются в различных местах, модулях, функциях, классах и т.д. Как правильно инициализировать эти данные? Правильно ли я понимаю, что принято в таком случае создавать какой-то конфигурационный файл, инклудить его в в самом начале и в нем уже определять все нужные значения? Это должны быть глобальные переменные? Или статические? Или же лучше и вовсе создать отдельный класс, методы которого возвращали бы эти значения?
Или правильнее использовать константы, типа:
define('LIB_PATCH', '/lib');

Опытные программисты, дайте пожалуйста совет или наводку как это правильно организуется!

Answer 1

[Дмитрий Коршунов]

По своему опыту:
----
"универсальные" настройки пишу так:
define('DIRSEP', DIRECTORY_SEPARATOR);

"уникальные" настройки (те что уникальны для конкретного сайта на одном движке) храню в JSON с последующим преобразованием в массив.

Answer 2

[Сергей Протько]

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

Более тру вэй, использовать штуки типа dependency injection container, например рекомендую PHP-DI. Скажем у вас по хорошему все должно быть разбито на компоненты, и вы просто указываете фабрики этих объектов, передавая все настройки в конструктор или в сеттеры. В этом случае компоненты будут знать только то, что нужно только им, а у вас будет одно центральное место для задания конфигурации всех компонентов.

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

Comments

[Arris]

Вам не кажется, что это слишком сложно для цирка, точнее небольшого движка сайта? :) Скоро будем писать hello_world() с помощью фабрик фабрик? :)

[Сергей Протько]

@Arris, нет не кажется. Я за автоматизацию рутины. Если можно что-то не писать, я стараюсь этого не делать, а бутстраппинг компонентов движка дело довольно утомительное.

Можно конечно писать все как всегда, иметь жирные классы которые умеют много всего, иметь архитектуру при которой класс работы с базой умеет еще и валидировать данные... Если для вас цель просто написать проект и забыть, то ок. Но у проекта есть срок жизни, и скорее всего придется его рефакторить, добавлять новый функционал и много чего интересного. А есть еще штуки странные, как автоматизация тестирования, при котором штуки типа dependency onjection экономят массу времени и нервов.

Даже с точки зрения обучения - лучше сразу учиться правильным вещам.

[Arris]

Я бы не назвал бездумное преклонение перед ООП правильной вещью. Чем больше я наблюдаю за модными "технологиями" - тем больше вижу - люди уже забывают, что такое "функциональное программирование". Зачем, если можно натырить в инете стопицот библиотек и классов, скопировать с стековерфлоу или хабра примеры, задать тупые вопросы на тостере и получить на выходе "гинеальный старттап"

Хинт: о новом функционале стоит задуматься еще на стадии написания первой версии. А насчет автоматизации тестирования, я вам так скажу: я конечно не гуру тестирования, но есть у меня нехорошее ощущение, что автоматизация тестирования появилась после автоматизации процесса разработки.

Когда мы будем писать hello world при помощи фабрик фабрик? Или может быть УЖЕ?

[Сергей Протько]

@Arris, вы не путаете функциональное с процедурным? ООП не ограничивает вас в применении парадигм функционального программирования. Более того, функциональное программирование не решает поставленных автором задач, но активно применяется внутри отдельных методов каких-либо классов.

По поводу "автоматизации разработки", вы перегибаете палку. С такими мыслями стоит отказаться от компиляторов и интерпритаторов, так как они автоматизируют и генерируют код за нас, когда мы пишем все на более приятных языках.

Да и потом, Бизнес-логику вам все-равно писать придется, а если при этом не придется писать кучу сервисного кода, то оно же хорошо. По поводу нового функционала, вы часто встречали проекты где требования и планирование нового функционала настолько далеко идут вперед, что можно за пол года предугадать развитие проекта? Я - нет. Частенько случается так, что требования к функционалу меняются уже вскоре после релиза очередной версии, что при сильной связанности системы превращается в очень трудозатратную задачу. С такими проектами проектировать систему с оглядкой на будущее становится просто нереально, и единственное что остается, проектировать систему так, что бы внесение изменений не вызывало много проблем. Это так же подразумевает юнит/интеграционное/функиональное тестирование что бы уменьшить количество регрессий и уменьшать задержки при доставке нового функционала.

Но никто конечно же не отменяет рационального мышления, программирование ради программирования тоже до добра не доводит. А "писать helloworld при помощи фабрик фабрик" попахивает нерациональным использованием инструментов.

С другой стороны, со всеми этими штуками аля PHP-DI, Composer, Symfony/HttpRequest, количество кода, позволяющее в кратчайшие сроки добавлять новый функционал, рефакторить не боясь регрессий, и в конечном итоге делать то, за что разработчику платят качественнее, снижают количество рутины при разработке и в конечном итоге и разработчик и клиент при грамотном подходе сохраняют больше нервных клеток за время разработки.

[Сергей Протько]

Symfony/HttpKernel*

Answer 3

[Виталий Желтяков]

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

Answer 4

[GM2mars]

Лично я в своем проекте создал отдельный файл config.php где лежит один объект конфигурации, и в начале index.php просто его инклудю. А в каких частях нужно, вывожу конфигурацию.
Может это конечно звучит не совсем "профессионально", но я не любитель "правильного геморроя" и не усложняю простых вещей.

Comments

[Arris]

Вопрос в том, как внутри файла хранить конфигурационные переменные :)

Можно, например: class something extends someconfig {}

[GM2mars]

Давайте начнем с того, что у вас считается конфигурацией? У меня кофиг файл содержит мета информацию о сайте (титул, описание, ключевые слова) и подключаемые css стили и js скрипты.