Дмитрий, Меня вполне устраивает Symfony. Работал с Laravel, вот так реально кромешный ад, все связано. Active Record это хрень, которая разрастается как не пойми что. Фасады и прочее, что сделано также для конечного пользователя, чтобы было проще. Очень рад, что ушел на Symfony. Крутая штука. Поэтому не думаю, что мне стоит менять фв. Он выполняет функции, для которых он мне нужен )
BoShurik, но Вы привели хороший пример наследования от своего класса, в котором, скорее всего, нет дерганий через get всех сервисов. А базовый контроллер как основа, но с нормальным кодом это отлично. Для этого оно нам и нужно
Дмитрий, ох, если для вас фреймворк это базовый класс контроллера, то какой смысл рассуждать? Почитайте как писать тестируемый код ) Документированные вещи это хорошо. Многое в симфони, к сожалению сделано для людей, который не хотят разбираться как сделать лучше для поддержки в будущем, а удобно здесь и сейчас. Точнее сказать сделано там все хорошо, можно и так и эдак писать, но в доку частенько вылезают такие вот моменты.
Дмитрий, Максим ниже ответил. Дополню, я не пишу свои велосипеды. Это обычный DI, а тащить целый сервис это расточительно и любая магия должна быть наказуема. Если я приду на проект и увижу вызов через get какого-то сервиса, мне придется найти в доке как вообще показать все сервисы, из всего списка найти, что за сервис и т.д. длинная цепочка = больше времени на изучение. Да, контроллеры обычно не тестят, но даже если захотеть при Вашем подходе, это крайне неудобно. Я, к примеру и аннотации не использую, потому что это связывает мой код и код фреймворка и добавляет неявно в мою сущность класс. Зачем это? Проще создать конфиг и там это прописать и заметьте, я опять же не отказываюсь от возможностей фреймворка )
Дмитрий, или не совсем понял Ваш вопрос. скорее вы имели ввиду почему не сделать new? Если так, тогда это приведет к жесткой связи. Все зависимости, кроме DTO или сущностей, которые просто хранят значения, необходимые классу лучше передавать через dependency injection. Это в свою очередь приведет к ряду плюсов, из которых в том числе более чистый код, меньшая связанность и как следствие более простая поддержка и возможность тестирования
Да, разобрался, мне приходит не просто Id в данном случае $id = current($classMetadata->getIdentifierValues($value)); А объект типа Uuid, я не учел, что она автоматически не преобразуется в строку. Спасибо за наводку. Завтра перепишу под свои нужды
Да, уже это прочитал... Жалко, что по дефолту такое не поддерживается. Нашел решение https://gist.github.com/webbertakken/569409670bfc7... мне кажется, оно похоже с Вашим. Но там есть одна проблема при обновлении сущности с теми же данными он считает, что это разные объекты и пишет, что поле уже есть. Ваша реализация лишена такой проблемы?
Спасибо, да, немного не так описал. Скорее проблема была в том, что необходимо иметь возможность создать несколько сервисов по примеру user_exists_checker, но в каждом новом сервисе будут новые реализации интерфейсов (Repository и UniqueEntityInterface), как это можно задать? По вашей статье не понял.
Вот у нас общая реализация App\Repository\User\DoctrineUserRepository, которая будет создана если передадут параметр App\Repository\Repository.
теперь мне нужно создать сервис класса App\ExistsChecker и ему уже передать другую реализацию
BoShurik, как-то все ну очень забавно работает. 'error_bubbling' => true такое поведение можно вызвать еще при создании дто и дата мапера, как оказалось. Теперь есть сущность, дто, дата мапер и валидация в validation.yml теперть получается для дто и все было бы круто, но теперь необходимо наоборот выводить ошибки не через {{ form_errors(form) }} все сразу, а для каждого поля отдельно, но с такой архитектурой не хочет работать больше {{ form_errors(form.firstName) }}, сталкивались?
BoShurik, Я понял ошибку, я выводил ошибки вот так {{ form_errors(form) }}, как оказалось так выведутся только если указать 'error_bubbling' => true. Но разве нельзя, чтобы они по дефолту выводились всегда без данного ключа при создании класса формы?
Также вопрос, {{ form_errors(form) }} как кастомизировать вывод можно? Я знаю, что можно вывести по 1 {{ form_errors(form.firstName) }} но хотелось бы как-то в цикле, знаете?
Влад Григорьев, не совсем понял про приложение, которое что-то входит. Мне нужно тестировать код, который работает с базой, вставка, удаление, получение, это будет интеграционное тестирование поверх юнит