2015-08-10 3 views
0

Я написал небольшую библиотеку (https://github.com/dborsatto/php-giantbomb), которая выступает в качестве оболочки для API. Для работы в библиотеке необходимо 2 основные параметры конфигурации:Как обрабатывать конфигурационные файлы в библиотеке PHP

  • АНИ ключ
  • Файл, который описывает параметры API

Что такое предложил способ справиться с этими двумя файлами?

Ключ API, конечно, личный, поэтому его нельзя добавить в репозиторий. Но при этом я не могу написать функциональный тест для библиотеки в целом, ограничившись только модульными тестами для отдельных частей. Я вообще отказываюсь от функциональных тестов или есть способ сделать эту работу?

О другой конфигурации, в основном это файл YAML (https://github.com/dborsatto/php-giantbomb/blob/master/api_config.yml), который включает базовую конечную точку API и конфигурацию для каждого репозитория данных. На данный момент это обрабатывается классом Config, который отделен таким образом, что пользователь должен написать код клея и ввести данные в конфигурацию. Таким образом, тест легче тестировать, но в целом я чувствую, что он создает больший недостаток, чем просто позволить классу Config загружать файл, анализировать его и вести себя соответствующим образом. Каков наилучший способ сделать это? На данный момент в репозитории нет тестов, но я работаю над ним (наряду с рефакторингом кода).

ответ

0

Я предлагаю оставить конфигурацию вне вашей библиотеки; Я сделал что-то подобное для службы рассылки Mandrill, где я оставил разработчику управление конфигурацией (я работал в проекте Symfony 2). Для меня нет Config класса, только конструктора сервиса, который принимает ключ API и (опционально) массив опций:

public function __construct($api, $options = array()) 
{ 
    // My code 
} 

Когда мне нужно использовать мою службу внутри приложения Symfony 2, я беру необходимый параметры и конфигурация из места (файлы конфигурации Symfony), внешние по отношению к моей службе; таким образом я могу отделить библиотеку от конфигурации. Разумеется, диспетчер служб генерирует исключение, если отсутствуют обязательные параметры.

+0

Я хотел сделать Bundle над этой библиотекой для более удобного использования с Symfony, и в этом случае это то, что я сделал бы. Но в среде Symfony это проще, потому что конфигурация централизована, и на самом деле Symfony отвечает за код клея. Как отдельная библиотека, я не уверен, какой будет лучший вариант. Может быть, чтобы Config загрузил конфигурацию по умолчанию, если она не указана? –

+0

Я полностью согласен с конфигурацией по умолчанию (если это применимо: если мне нужно передать свой идентификатор API, он должен быть обязательным параметром без по умолчанию). В общем, я все же считаю, что лучше сделать вашу библиотеку полученной конфигурацией из внешнего источника: «Чтобы использовать мою библиотеку, вам необходимо передать параметры A, B и C», и вам все равно, как и где эти параметры управляются , –

+0

Вместо того, чтобы рассказать о создании простого пакета Composer? Просто, чтобы не быть строго привязанным к Symfony;) ​​ –

Смежные вопросы