# Delphinum (20.01.2017 / 21:11)
На деле вариант 2 более распространен, потому что ты не издаешь стандарты чтобы пользовать вариант 1, ты пишешь готовые решения, которыми будут пользоваться. Другими словами если ты будешь создавать п
Тут далеко не для любого проекта.
Если пишешь простой движок на спагетти-коде с частичным использованием ООП, или юзаешь простые фреймворки, типа Godeigniter, Yii ну или другие, но в традиционном стиле, то тут речь не идет.
Я же имел в виду самый современный подход, где центром системы является контейнер сервис-локатор, работающий на конфигах. Пример:
https://github.com/john-cms/jo ... p#L20
Когда мне нужен переводчик, я знаю, что у меня для этого в API есть интерфейс Translator\TranslatorInterface::class я его из контейнера и требую. А уж контейнер сам выдаст нужную реализацию, которая была у него прописана в конфиге.
API нет смысла дробить по пакетам, ибо реализация может меняться.
Вдруг я завтра вообще захочу заменить один пакет другим, более надежным, но реализующим тот же интерфейс. Модули этого и не заметят.
Посему, чем выискивать API по пакетам, логичнее собрать все интерфейсы в одном пакете.
reaper, это не удивительно, в последнее время PHP так сильно изменился, что многие до сих пор не могут прейти к общему мнению по поводу пакетирования и модульности. Я придерживаюсь рекомендаций Zend'а )
# Delphinum (20.01.2017 / 21:21)
Я придерживаюсь рекомендаций Zend'а )
Я уже много лет как всем это советовал и сам придерживаюсь.
У них наиболее хорошо и что главное логично все продумано и описано.
AlkatraZ, в плане самых современных решений в PHP я согласен, сначала ты указываешь зависимости от пакетов-интерфейсов, затем подбираешь для каждого пакет-реализацию и все это миксуешь в своем контейнере. Это правильно и удобно. Мастхев так сказать.
# AlkatraZ (20.01.2017 / 21:22)
Я уже много лет как всем это советовал и сам придерживаюсь.
У них наиболее хорошо и что главное логично все продумано и описано.
да, но из за этого порог вхождения сумасшедший. Я убил около года на изучение Zend при том, что активно почитывал книги, доку и практиковался на реальных проектах. Ну уж очень много там у них всего реализовано на все случаи жизни.
Delphinum, я имел ввиду что между модулями могут быть тоже зависимости, то есть response ожидает request определённый, а то что модуль несёт в себе свой интерфейс, то оно не факт что совместимо
Кстати, Zend Отлично собирается в .phar архив и работает
.gif)
Вот пример:
forum/index.php?type=topic&id=5843
Я как то набросал RSS агрегатор на Зендовских пакетах. Экспериментировал разумеется для Моби, но потом подумал, что такой легальный "граббер" может быть полезен другим, но вот выгружать микромодуль, в котором файлов в 4 раза больше, чем во всем движке вместевзятом нелогично.
Посему, запаковал все в PHAR и отлично работает.
AlkatraZ, ну сам 3енд рекомендует писать пакет независимый, чтоб легко можно было собрать архив и использовать, например модуль acl
# Koenig (20.01.2017 / 21:30)
AlkatraZ, ну сам 3енд рекомендует писать пакет независимый, чтоб легко можно было собрать архив и использовать, например модуль acl
Ты не забывай ДЛЯ ЧЕГО я писал
Для старого Джона, там такие понятия, как пакеты и ACL не существуют. А модуль написан на Zend Framework.
Посему и пришлось упаковать, зато получилось всего 3 файла.
в пхар хотя бы утечку памяти то пофиксили? че то я как то забыл поинтересоваться
