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

и начинаем обсуждать сроки и скоуп

Это не отменяет факта что ты будешь рефакторить.

как это простите связано?

если сущности изолированы, поведение четко очерчено

есть моменты в которых их поведение будет изменено

но оно покрыто тестами и покажет, где сломано

И у меня порыто тестами. И бехат и юнит.

И показывает, где ломается.

Блин, ок, чувак.

Я тебя услышал

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

в репо мы пишем только работу с таблицами (получить данные, сохранить данные), правильно? 1. из контроллера или сервиса обращаюсь к методу в репо (получить данные) 2. в контроллере или сервисе, делаю необходимые операции с данными 3. чтобы записать результат эти данные передаю назад в репо

есть практика тонких контроллеров

это проще покрыть тестами и реиспользование кода улучшается

вся логика на обработку данных в сервисах, репо делает обычно лишь персист готовых сущностей и выдачу по фильтрам

архитектура MVC хороша до момента появления предоставляемого для автоматизации апи, дальше приходится делать слои (авторизация, валидация, трансформации в нужный формат, версионирование) и в этот момент на сцену выходят мидлвари

в 4й версии планируют мидлвейр интересно или как в 3й на ивентах городить

а чем ивенты не устраивают?

сильно широкая область применения , те же ларавелевские мидлвейр как-то проще по структуре и понимания

привет, ипользую fosrest. Есть такая задача, нужно где-то для половины роутов наличие обязательного кастомного заголовка, как лучше такую ситуацию разрулить?

ивентами)

да, ими родными =)

у меня много входных данных на лету трансформируется на ивентах

создал листенер на kernel.request, мне нужно для половины роутов если заголовка нету кидать exception, а для остальных ничего не делать. Как с роутами быть не понимаю

у тебя в ивенте доступа информация по реквесту и контроллеру

выбирай по каким-нибудь признакам и бросайся эксепшенами

типа по FQCN контроллеров

а что-нить типа кастомной аннотации у контроллера можно сделать?

да

можешь кастомные параметры к роуту просто добавить

понял, спасибо!

А я вот не понял по-поводу мидлваров

Можно же написать ивент листенер, который будет смотреть на: public function secureAction(MiddlewareFilterByUserAge $middleware) при каждом запросе. Оттуда потом получать объект этого мидлвара и запускать его.

По-любому уже есть че нибудь готовое

Написать свое на базе psr7

Все готовое как yii, очень специфичное

Раньше диакторос был

Ща есть спека

Старайтесь без аннотаций, проще парсер на неоне подключить

И иметь котлеты отдельно от мух

Yaml тяжеловат по ресурсам

Всем привет. Подскажите, а где для дактрины для типа array найти дефолтное значение? достаточно долго уже ищу, найти не могу

http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#array-types

http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#array-types

Спасибо!

совет по доктрине. не пытайтесь кешировать записи по айдихе и делать методы типа getById вместо стандартного find

в моей практике именно оверюс find приводил к аду

если что-то надо - надо писать dql

как именно приводил?

в бизнес логике редко идет поиск по одному полю

эм

я говорю за find по айдихе

первичный ключ, а не поиск по какому-то полю

ребята сначала пытались сделать findBy([])

и это характерно убивало бд

не, findBy это другая история

вообще лучший способ это иметь prepared statements

для таких вещей заводить нужно отдельные методы в кастомных репозиториях

ваще доктрина очень плохо дружит с неинтовыми айдишниками

uuid нормально живет

uuid это инт)

если у тебя инт на 128 бита тогда да

uuid нормально живет

UUID - очень плоорй ID если говорить о поиске по нему.

И о скорости

Его невозможно эффективно индексировать

ERROR: S client not available

И почему UUID -это int?

123e4567-e89b-12d3-a456-426655440000 Это вроде как никак не int

Его невозможно эффективно индексировать

с какой это радости?

Потому что не строится по нему бинарное дерево

Нормальное

Огромное и не быстрее чем обычный поиск

123e4567-e89b-12d3-a456-426655440000 Это вроде как никак не int

BigInt на 128 бита, если убрать дефисы и перевести из хекса

А ок. Не задумывался.

Тогда вопрос с поиском отпадает наверно

Потому что не строится по нему бинарное дерево

нет с этим проблем

Если хранить как текст - есть

храни его в бинарном виде

в 16 байт влазит

А по нему можно нормально искать?

Бинарный как PK?

Новый мир какой-то для меня :)

да, нет никаких проблем с ним

в кассандре и других распределенных базах же живут как-то без инкрементов

Ну это же не SQL базы данных

Я понимаю, что и в монде там Object ID Не простой int

Но мы-то говорим про MySQL, PgSQL и т.д.

Если писать PK как UUID текст, проблемы со скоростью поиска очень быстро появятся по мере роста данных

Если писать PK как UUID текст, проблемы со скоростью поиска очень быстро появятся по мере роста данных

Почему?

Потому что текст уникальный, не индексируемый нормально.

http://thebuild.com/blog/2015/10/08/uuid-vs-bigserial-for-primary-keys/

Вот этот текст утверждает обратное

есть стенд от перконы

Потому что текст уникальный, не индексируемый нормально.

Ты пробовал сам? Есть конкретные цифры?

https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/

Сам не пробовал. Говорю на основании того, что читал где-то.

Допускаю, что могу ошибаться.