Как правильно использовать вложенные бандлы?

grabbee,

Я уже пробовал. Обновлять это потом как? Я переписываю и обновляю "общие вещи" регулярно. Лезть потом в каждый и править там?.. Это ночной кошмар, как по мне))

Предполагаю что общие вещи действительно в кавычках) Жить это может в бандле, но лучше запустить отдельным сервисом и вообще не париться не за что. Так как в бандле всё равно есть вещи работающие с базой, например. При изменении структуры базы вам в каждом приложении нужно думать как мигрировать данные и точно так же сидеть ночами. Это лишь один пример)

Я уже в этом месте :)

Поздравляю. Вы «на правильном» пути)

Но я пока не ощутил что лучше. Проблемы с зависимостями или проблемы с дублированием кода. Решение конфликтов зависимостей багов не привносит. А отдельные версии кода - я через два дня забываю где что писал))

Значит ваш бандл простой, мало изменяется и такие же приложения. В серьёзном проекты вы бы получили массу проблем и багов. Это может пойти по разным путям. Где-то будут миграции мешать, где-то php72, а где-то уже php81 и т д. Если не встречались с проблемами - не значит что они не будут) Как я уже говорил - идеально вынести в отдельный сервис и взаимодействовать по api. Но тут уж сами решайте. Здесь точно такая же проблема, как с универсальной моделью, в которой у вас есть User с 50-100 полями в базе. Да, вы ничего не копируете, всё есть в User (и даже чего не надо), но такая запутанность даёт много проблем. Например, null поля. В разных контекстах этот же User может быть Автором, Покупателем, кладовщиком, поваром и т д. И все 50 полей распределятся по контекстам.

Как правильно использовать вложенные бандлы?

grabbee, Вы слишком не правильно понимается принцип DRY. В вашем случае лучше эти все вещи скопировать в каждый свой проект, либо этот бандл сделать полноценным сервисом/микросервисом - Auth. Вполне себе хороший сервис. С такими темпами вы придумаете бандл для приложения, чтобы бандл сразу в трех приложениях делал всё общее для трех приложений. Путь в никуда с жесткими зависимостями)

Если уж совсем не хочется так, то можно жить с этим как объединив, так и не объединив. Настройки для бандла Б можно включить в бандл А и всё будет работать)

Роутинг согласно пути файлам?

Владислав,

А есть вариант чтобы при написании 127.0.0.1:8000/api/v1/client
Он брал контроллеры из папки v1,v2, и т.д без создания доп. блоков которые вы указали выше ?

Такого не помню. Если только создать свой сервис генерации url. https://symfony.com/doc/current/routing/custom_rou...

Роутинг согласно пути файлам?

Владислав, да) Для каждой версии нужно будет указать свой префикс. Тут уже сами решайте пойти по пути дублирования версии в пути контроллере или для каждой версии создавать свою группу.

api_v1:
    resource: ../../src/Http/Controller/Api/V1
    prefix: /api/v1
    name_prefix: api.v1.
    trailing_slash_on_root: true
    type: annotation
    defaults:
        _format: json

Как поставить интерпретатор php в PhpStorm нужной мне версии?

Daria Motorina, полностью согласен с Алексей Уколов. Это всего лишь подсказка для phpstorm о версии в проекте. Его можно изменить вопреки composer.json. То о чем вы говорите это, так называемый, PHP Language level, а не интерпретатор.

Возможно ли в yii2 настроить Last-Modified?

shik0, смотрите на изменение файла вместо запроса в базу.

Что принципиально отличает Symfony 5 от Laravel 8?

DevMan, да, спасибо)) Исправлю. Как раз хотел сказать об этом) просто писал ответ ночью не сильно думал)

Что принципиально отличает Symfony 5 от Laravel 8?

Роми, а для email писем?)))

Что принципиально отличает Symfony 5 от Laravel 8?

Максим Федоров, ахах. Это чтобы показать Заказчику, как много работы мы сделали. Больше строк — больше денег!)

Что принципиально отличает Symfony 5 от Laravel 8?

Роми,

Ну, значит, я чего-то там с Doctrine недопонял)) что в общем, не удивительно - я просто клал данные в таблицы и доставал их оттуда)) и простые отношения, без всяких полиморфных наворотов))

значит у Вас были простенькие проекты, в которых было мало бизнес-логики, мало изменений, разделений, рефакторинга. Любое изменение нейминга будет для вас мучительным. Любой инструмент надо подбирать под задачи. Если Вас это устраивает, то используйте это. Да хоть вообще на прямых подключениях через mysqli без всяких фреймворков.

Что принципиально отличает Symfony 5 от Laravel 8?

Роми, причем тут Doctrine? Doctrine можно и в Laravel поставить и в Yii2) Если Вы хотите в таком ключе получить ответ, то ещё и twig вместо blade :-)

Как структурировать проект на Symfony по принципу package-by-feature?

sgidlev,
Нужно импортировать папки в главном services, например
config/services.yaml

imports:
  - { resource: services/ }

Либо настроить импорт прямо в src/Kernel.php
А далее уже каждый конфиг помещаем в настроенный путь.
config/services/auth_system.yaml

services:
  _defaults:
    autowire: true      # Automatically injects dependencies in your services.
    autoconfigure: true # Automatically registers your services as commands, event subscribers, etc.

  App\AuthSystem\:
    resource: '../../src/AuthSystem/'
    exclude:
      - '../../src/AuthSystem/Entity/'

  App\AuthSystem\Entity\User\UserRepository: ~

doctrine:
  dbal:
    types:
      auth_system_user_id: '\App\AuthSystem\Entity\User\IdType'
      auth_system_user_alpina_user_id: '\App\AuthSystem\Entity\User\AlpinaUserIdType'
      auth_system_user_token: '\App\AuthSystem\Entity\User\TokenType'
      auth_system_user_role: '\App\AuthSystem\Entity\User\RoleType'
      auth_system_user_alpina_role: '\App\AuthSystem\Entity\User\AlpinaRoleType'

  orm:
    mappings:
      AuthSystem:
        is_bundle: false
        type: annotation
        dir: '%kernel.project_dir%/src/AuthSystem/Entity'
        prefix: 'App\AuthSystem\Entity'
        alias: AuthSystem

Как структурировать проект на Symfony по принципу package-by-feature?

sgidlev, если говорить о вашем примере, то я бы сделал так:

docker/
bin/
config/
    services/
        order.yaml
migrations/
public/
    index.php
src/
    Http/
        Api/
            Auth/
    Console/
        Order/
    WebMoney/
        Client.php
    Yandex/
        Client.php
    Cart/
        Entity/
             Cart.php
             CartRepository.php
    Infrastructure/
        Cart/
        Order/
    Order/
        Entity/
    Kernel.php
templates/
    order/
tests/
translations/
var/
vendor/

Но это чисто сугубо моё мнение основанное на Вашем примере, без всех входных данных и требований. Где-то заложен компромис, например, репозиторий - это инфраструктурная вещь, он требует интерфейс между слоями, а реализацию в Infrastructure, но расчёт здесь на то, что если мы будем переносить фичу, то не будем менять доктрину на другую ORM. Так же и аннотации пишем в сущности доктриновские. Мы понимаем их зависимость и нас это устраивает для быстроты работы. В противном случае мы должны делать интерфейс, а аннотации писать в xml или yaml в папке инфраструктуры.

Я бы ещё подумал над папкой Infrastructure. Возможно её лучше перенести в каждую фичу.

Как структурировать проект на Symfony по принципу package-by-feature?

sgidlev, а чем вас не устраивает структура данного проекта на Slim? В нём как раз применён данный подход. Вам нужно разобраться в данной тематике, попробовать, а не делать под копирку.

Суть данного подхода Архитектуры в том, что каждую фичу вы раскладываете на папку или класс, если фича умещается в один класс, то папку для фичи можно не создавать. Внутри фичи Вы можете делать любую структуру. В этом и суть этого подхода - изолировать каждую фичу от остального кода. В последствии, в крупных проектах уже создаются команды под фичу, а так же фичи могут быть вынесены из монолита в микросервисы. Если код в монолите, то при изменении фичи у них не будет конфликта с другими фичами монолита, так как они связаны через интерфейс и имеют реализацию интерфейсов в Insfrastructure. Только эта папка может иметь связь со всеми фичами. В остальных папках используется интерфейс или событийная связь. Папку Infrastructure можно сделать общей на весь проект, а можно положить и в каждую фичу. Но тут опять решать только вам…

Как вы понимаете, здесь по примеру не пойти. Архитектура всегда сложная тема в проектах, она может меняться от проекта в проект, зависит от требований, команды и много чего. Здесь нужно разбираться. Вы не обязательно можете смотреть уроки для php. Архитектура - не относится ни к какому языку. Можете посмотреть уроки на Java и других языках.

Как структурировать проект на Symfony по принципу package-by-feature?

Максим Федоров, согласен) Главное понимать обе стороны. От всех правил можно отступать, если есть понимание всей картины.

Автору нужно попробовать оба варианта в реальном проекте, чтобы понять плюсы одного и плюсы другого)

Как структурировать проект на Symfony по принципу package-by-feature?

Максим Федоров, согласен, можно контроллеры помещать прямо в фичу) в этом нет никакой проблемы. Лично я отделяю эти контроллеры, как раз для Gateway. Да и в целом понял, что принципе это удобнее. Так же как в фичу мы не тащим templates и translations, конфиги сервисов. Хотя и их можно туда поместить при желании) Тогда фича будет полноценной.

В моей папке контроллеров также имеются подписчики для Api, которые отдают доменные и ошибки валидации в нужном формате. По сути это Middleware. А так не понятно куда их ложить становится) Но это каждый сам выбирает как лучше. И так и так имеет место быть.

Как структурировать проект на Symfony по принципу package-by-feature?

sgidlev, тогда и он всё объяснил и есть пример на slim) Он не сильно отличается от symfony.

Yii2 SluggableBehavior не генерит slug при создании объекта из очереди /queue?

zifmezin, ну видите сами. Зависит от окружения. Yii2 тут не причём. Ищите проблему в неустановленном на проде расширения php-intl. Запустите скрипт из консоли на проде. Если не отработает, то вы знаете где искать проблему.

В чем преимущество "фабричного метода" перед простым созданием объектов?

Дмитрий, это компонент) По аннотациям доктрины понятно, что используется в Симфони) Без бандла.

Как получить подстроку из строки php?

FanatPHP, про кусок согласен, но эти точки, как вы сказали проковырянные «палкой с гвоздём»)