Контакты

Наибольший вклад в теги

Все теги (10)

Лучшие ответы пользователя

Все ответы (9)
  • Как делать пакеты как у Symfony?

    ghost404
    @ghost404
    PHP Developer
    У меня есть опыт такого подхода.

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

    Не думаю что у вас есть в это особая необходимость. Но вы можете разработать какие-то свои компоненты и вынести их в отдельные репозитории и устанавливать как зависимости. Можно даже сделать их open source и сообщество может вам помогать в их разработке и сопровождении.

    Как и сказал BoShurik, бандл это уровень интеграции компанента в фрайморк. Выделяя компонент в отдельный репозиторий вам нужно и бандл выделять в отдельный репозиторий. Так у вас будет 2 отдельных git репозитория.

    Таким образом у вас будет следующие git репозитоии:
    - ядро проекта
    - компонент блога
    - бандл блога
    - компонент мероприятий
    - бандл мероприятий
    - компонент деятелей
    - бандл деятелей
    - компонент аккаунта
    - бандл аккаунта
    и др. х2

    Разделение проекта на много независимых репозиториев это не есть плохо. Как и разделение проекта на микросервисы. Но у этого подхода есть существенный недостаток. Часто нужно внедрять новые фичи или править баги которые требуют внесения изменений в несколько репозиториев одновременно. Это доставляет массу неудобств. Особенно когда нужно проходить через этап релиза. Протестировать в проекте работу правок можно только после внесения их в бандл и релизе его, а зарелизить бандл можно только после его тестирования, а тестирование бандла требует тестирования и релиза компонента, а делать релиз компонента не убедившись как оно будет работать в конечном продукте нельзя. В общем релизный ад. Я проходил через него и не советую другим. Это осмысленно только для больших проектов с большой командой разработчиков.

    Как и сказал BoShurik, разделяйте проект на независимые модули и организуйте модули в папки и неймспейсы. Я пользуюсь этим методом уже несколько лет. Полет нормальный.

    App/Blog/Controller
    App/Blog/Entity
    App/Events/Controller
    App/Events/Entity


    Разработчики Symfony зря советуют не использовать бандлы. Ваши модули по сути и будут бандлы. Вы создаёте в модуле бандл в котором описываете метод интеграции модуля с фреймворком.

    App/Blog/AppBlogBundle
    App/Events/AppEventsBundle


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

    Касательно того как всё устроено конкретно в Symfony. Я довольно давно изучал этот вопрос и могу ошибаться в деталях.
    В Symfony когда-то использовался git submodules для компонентов. Но от этого решения отказались. Оно не очень удобное, особенно для конечного пользователя. В плане разработки это чуть удобнее чем отдельные пакеты на мой взгляд.
    Сейчас всё работает иначе. Есть основной репозиторий symfony/symfony. Все компоненты находятся в нем. Всё правки вносятся в него. В репозиториях компонентов никакой активности нет. При коммитете или пуше в ветки symfony/symfony запускается хук который на отдельном сервере SensioLabs запускается специальная утилита которая копирует все коммиты сделанные в компонентах из symfony/symfony в репозитории соответствующих компонентов. Мне как-то попадался сайт SensioLabs на котором можно было скачать эту утилиту.
    Суть в том, что это не репозиторий Symfony состоит из репозиториев компонентов. Это компоненты Symfony по сути выдранные куски кода из основного репозитория.

    Я когда-то тоже хотел сделать приложение с выделенными модулями в отдельные репозитории как у Symfony, но разобравшись в вопросе я пришел к выводу, что мне это не подходит. И вам думаю тоже не подойдёт.
    Ответ написан
  • Архитектура Entities в Doctrine, Symfony 4 - кто может помочь?

    ghost404
    @ghost404
    PHP Developer
    Есть такая штука как предметная область (Domain). Предметная область состоит из моделей (в Doctrine это Entity), сервисов предметной области и много чего ещё.

    На сколько я понимаю из ваших комментариев, у вас есть 3 интерфейса (UI) которые работают с единой предметной областью. В этом случае не нужно дублировать бизнес-логику под каждый интерфейс. Правильней выделить бизнес-логику в отдельный субъект и реиспользовать его в ваших приложениях с интерфейсами.
    Можно организовать код вашей бизнес-логики в самостоятельный модуль, вынести в пакете Composer и оформить как Symfony Bundle, что вы и сделали.

    Если же у вас есть несколько независемых проектов/сайтов у которых схожая предметная область с небольшими отличиями, то я рекомендую не использовать одну реализацию бизнес-логики на все проекты и рекомендую продублировать код во все проекты.
    Поясню. Поначалу, на маленьких проектах кажется хорошей идеей реиспользовать код, но со временем проекты развиваются и развиваются они как правило независимо друг от друга. С развитием отдельных проектов может, и скорей всего будет, изменяться бизнес-логика соответствующих проектов и вам придется вносить изменения в единый код для всех проектов. Таким образом изменения будут применяться не только в том проекте где они нужны, но и в других проектах которым эти изменения не требуются. Это может нарушать бизнес-логику других проектов, приводить к конфликтам и неожиданным ошибкам. Этот подход имеет право на жизнь, но нужно оценивать риски и всё тщательно взвешивать. Моя практика показала, что ни к чему хорошему это не приводит.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (5)