Алексей Павлов: как вы думаете сколько в самой Symfony кода, как в ваших примерах? А теперь найдите там статику.
Лучше уже тогда функцию в namespace определить.
Владислав: Кстати преобразование 1000 => 1K, это вообще View слой -> Twig расширение, зачем вам для этого нужна функция? Еще раз повторю, если у вас есть такие классы с набором общих функций, значит вы неправильно спроектировали приложение. Но все это касается только академически правильной разработки.
Трейты? Я ничего не говорил про трейты и использовал вообще их только пару раз в проектах в очевидных случаях, помоему потом еще и жалел об этом. Трейты также связывают ваш код и добавляют зависимости. Их использование спорный вопрос.
Михаил Шатилов: Скиньте конфигурацию DI контейнера, то что вы передаете в NewsletterManager и как у вас инициализирован в DI репозиторий. Ошибка именно ваша.
Олег Титаренко: Вообще кейс странный, и нахрен в одном проекте нужно 10 composer.json я вообще не понимаю. 1 проект - composer.json, 1 либа - 1 composer.json, впервые такую дичь вижу.
Владислав: Laravel не является примером хорошей архитектуры, причем здесь Laravel если вы пишите на Symfony. Идеология такая - ты должен создать объект перед тем как его использовать. Чище создать helper в DI контейнере и внедрять его там где нужно, чем иметь этот хелпер в глобальной области видимости. https://phptime.ru/php-features/pochemu-nekotorye-...
Владислав: Старайтесь не делать так. Это нарушает принципы SOLID. Статические методы - всегда неявная зависимость в коде, которая усложняет его тестирование, и делает невозможным моки этой функции.
hrvasiliy: vendor установит composer install, остальные походу тоже сам Laravel создает, не писал на нем, точно не знаю. Если они по дефолту в гит игнор, значит эти файлы\директории создаются при деплое\запуске каких то утилит в Laravel
Изучив Yii ты будешь знать Yii, изучив symfony - тебе пофиг на каком фреймворке писать или без него. Базовые знания архитектурных решений, без которых на Symfony в отличии от Yii ничего дельного не напишешь, дают очень много буста разработчику. Если хотите заработать на хлеб, ок, пишите на Yii, пишите много. Если хотите расти как разработчик и решили стартануть с php, то онли Symfony. Тяжело, долго, но знания, которые вы получите очень дорого стоят. Ну и выход в ентерпрайз приложения на Yii маловероятен, скорее даже невозможен, имхо.
Active Record как паттерн отстой, ибо совмещает в себе бизнес логику и маппинг данных на БД. Согласен, можно не писать логику в моделях, что не отменит того что модель Active Record это тупая таблица в БД. Примитивный шаблон для примитивных задач. Я как-то хотел свой старый проект на Yii привести в порядок, так там такая дикая связанность между компонентами, что сделать из него что-то под свои задачи слишком трудозатратно.
hrvasiliy: По поводу БД, конечно используйте миграции, старайтесь максимально приблизить локальное окружение к продакшену (именно поэтому лучше использовать виртуалку. Когда проектов становится много, сложно поддерживать кашу из энвайроментов на одной физической тачке). Также для разработческого и тест окружения используйте фикстуры, чтобы наполнять базу стартовыми данными.
Насчет CI, погуглите continuous integration, это отдельная и достаточно большая тема. Решений очень много и кастомизируемость их высокая. По сути это система(простым языком), которая подготавливает ваш код к отправке на prod сервера (на самом деле куда угодно, intergration, test...). То есть она может с нуля собрать ваш проект, вылить на тестовый сервер, применить миграции и фикстуры, запустить там тесты и если все ок, то вылить это все на продакшен сервер, при этом она может делать это автоматически, например по хуку из github. Я не DevOps инженер, поэтому рассказать все тонкости я не смогу =)
Да вижу. Все равно вопросов с маппингом у вас не должно быть. Вы указываете что поле с IDшником это объект, доктрина дальше сама разберется.
Вопрос про объекты, я пишу в своих проектах на объектах и пока не встречал проблем (единственное наверно, о чем можно задуматься это запросы через Doctrine Proxy, SecondLevelCache). Да, может быть в каких-то случаях есть оверхед на запросе к базе\кешу и гидрации, но я пока его еще не ощущал. В примерах самой доктрины, например, объекты: docs.doctrine-project.org/projects/doctrine-orm/en... Этот вопрос также для меня остается открытым, нужно подумать по этому поводу, но мне кажется управлять объектами проще визуально и лексически правильнее. Вы можете привести какие-либо замечания по поводу объектов?
Лучше уже тогда функцию в namespace определить.