Конечно пробовал ! По этому и прошу помощи с примером, может у тебя есть кусок готового конфига ? А то мне эти пустые наборы конфигурации ни о чем не говорят. Или снизойдешь и напишешь аналогию по примеру выше ?
Денис: меня просто вот это ввело в заблуждение:
------
Или создаваться и использоваться вообще разные сервисы в зависимости от версии api.
------
Обратная совместимость - это конечно должно поддерживаться, я не спорю.
По поводу симфоневского валидатора - этим как раз-таки пользуюсь, а обертка просто для обработки ошибок и привода их к красивому виду и бросание исключения (удобны исключения, приятно принимать в контроллере). Asserts-аннотации не использую, потому как входящие данные мне все равно нужно проверять, по этому проверяю сразу через CollecitonConstraint входящий массив аргументов, плюс добавляю либо кастомные Constraints - что очень удобно, либо дополнительную логику для проверки прям на месте, если необходимо.
Сериалайзер не подходит, потому как много логики основывается на полях было-стало, нужно для некоторых полей писать виртуальные свойства (это я от JMSSerializer набрался), плюс аннотациями забивать не хочется и т.д. Короче очень много дополнительной логики, что просто прямыми сеттерами не отделаешься.
Спасибо за ответ, хотел бы уточнить:
-----------------------------
По поводу
$data = $request->request->all();
Есть замечательные форматы, например json или xml.
По поводу
//throwing some ValidateException
Валидатор не должен кидать исключения, он должен просто возвращать ошибки.
---------------------------
По поводу вышесказанного, первое для примера. Хоть JSON, хоть FormData хоть XML - это не суть и к моей проблеме отношения не имеет.
Второе - наверное я ввел вас в заблуждение, но там типо кастомный сервис, который как раз-таки принимает ошибки валидации, преобразет их, и кидает исключение.
По поводу разных сервисов для разных версий. Мне кажется сервис не должен знать о существовании версии API, тем более, что новая версия может отличаться на уровне модели от старой, что накладывает обязанности на разные входные данные (между первой и второй версией). И мне придется, либо менять внутряк старых сервисов и использовать трансформацию данных, а потом в них же вызывать новый сервис куда буду передавать обработанные данные, либо делать трансформер в контроллере.
По поводу валидаторов, и сериалайзеров, которые вы скидывали - не подходят, пользовался и JMSSerializer и FormType и Asserts-annotation т.д. Оказалось проще и прозрачнее использовать свои обертки над валидаторами (на основе Symfony Validation Constraints конечно). Как и вместо сериалайзеров проще использовать сеттеры, потому как очень много приходится всего дописывать к этим сериалайзерам.
Т.е. привод к актуальному виду, поступивших данных - это работа в экшене контроллера, перед передачей этих данных в сервис, ну т.е. примерно то, что я пытался тут описать в вопросе ?
Дмитрий: а, понял. Ну самое простое, что приходит в голову - это сохранять в таблице access_path и через слушателя symfony.com/doc/current/cookbook/event_dispatcher/... проверять путь на соответствие access_path и если не соответствует, то кидать AccessDeniedHttpException() .
