ну то есть...

User сущность у каждого проекта должна быть своя

имеет смысл например сделать реюзабельный бандл который предоставляет что-то типа Credentials

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

и стратегии разные делать и много чего еще

userbundle на 70% проектов хватает, если что-то хитрое, лучше без него

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

userbundle на 70% проектов хватает, если что-то хитрое, лучше без него

у меня апишки

что означает что 80% кода этого бандла мне вообще нафиг не уперлось. И не хочу я что бы мои сущности имплементили какой-то там Userinterface

@fes0r ярый противник FOS бандлов) Во всех больших проектах, которые разрабатывал совместно с командой симфонистов - никогда не юзали фос бандлов, ибо нафиг не нужно, было бы много костылей

Спорно это всё.

Спорно это всё.

аргументируй)

ну то есть если тебе их хватает - ну ок

мне оно время не экономит а нервов потрепало немало

Да, скорее так. Пока не было проектов где прочитав пару манов по фосу что-то не мог реализовать.

вопрос не в том "смог или не смог"

вопрос как

Я понимаю что зачаскую для мелочи он избыточный, но для быстрого старта самое оно

Я понимаю что зачаскую для мелочи он избыточный, но для быстрого старта самое оно

для крупного он лишний)

Без костылей, стандартые "расширения"

Без костылей, стандартые "расширения"

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

если у тебя сущности это тупые хранилища данных и сверху есть настоящие сущности - то как бы и норм

тогда можно любой трэш спрятать

хотя будет не красиво

хз, 1kk в сутки, норм.

Всмысле тупые ? Не совсем понял

анемичная модель

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

куда ты его положишь?

и какие геттеры/сеттеры для этого тебе понадобятся ;)

слушатель на update ентити юзера, там правило валидации

хз, 1kk в сутки, норм.

вон вконтактик живет вообще с процедурами и не тужит. Не вижу корреляции количества запросов и качества кода..

Ну я думал мы в конце-концов придём к тому что фос избыточен -)

Кстати, вот всплыл вопрос по кешированию. memcached vs redis = один фиг ? кешить буду ответы АПИ

HTTP-cache первичнее

а сервер - похуй. берите то что умеете готовить

слушатель на update ентити юзера, там правило валидации

public function changePassword($oldPassword, $newPassword, $encoder) { if ($encoder->isValid($oldPassword, $this->password) { throw new PasswordMismatch(); } $this->passwordHistory[] = $this->password; $this->passwordHistory = array_slice($this->passwordHistory, -5); foreach ($this->passwordHistory as $password) { if ($encoder->isValid($newPassword, $password)) { throw new PasswordAlreadyHasBeenUsed(); } } $this->password = $encoder->encode($newPassword); }

Сейчас memcached на инстансах, смотрю в сторону redis кластера, есть ли смысл ?

1. явно 2. кохизив 3. легко тестить

можно вопрос не по теме?) туплю нереально...

Кстати, вот всплыл вопрос по кешированию. memcached vs redis = один фиг ? кешить буду ответы АПИ

с redis-ом можно прикольные штуки вытворять в плане инвалидации кэша

а так зависит от стратегии кеширования выбранной

p.s. а почему не заюзать какой-нибудь varnish или подобные реверс-прокси кэши?

пишу сейчас расширение для хрома, блин перестала форма реагировать на submit, не пойму в чем дело... $('.contact__form').on('submit', function(event) { console.log('WTF, man???'); }); тупо не отрабатывает

все, разобрался.. required поля если не заполнены (это никак не отображается) - submit не отрабатывает

анемичная модель

rest и анемичная модель друг без друга жить не могут

Почему?

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

а DTO?

единственное спасение

Feedback request https://github.com/json-api-php/json-api/issues/4

p.s. а почему не заюзать какой-нибудь varnish или подобные реверс-прокси кэши?

Исторически сложилось. Пришёл на проект, тут memcached, щас смотрю в сторону редис кластера

rest и анемичная модель друг без друга жить не могут

вообще-то могут)

единственное спасение

Read Model построй себе и радуйся)

p.s. я серьезно подсел на идею дергать из базы сразу DTO минуя сущности и т.д. Пока даже забавно

через рид модел и пдо фетч с объектом сразу?

через рид модел и пдо фетч с объектом сразу?

ну тип того, только возможно придется чутка поразвлекаться с pdo а не тупо замэпить на объект (в основном когда тебе надо результат выборки засэтить на граф объектов)

https://github.com/fesor/api-example/commit/6afecee21f983e7db151752a0c0b8fb5ea4db4ce

ну или можно так

правда это пока мега сырой прототип

моя прошлая контора тоже на рид перешла в этом плане,а то доктрина на больших объемах всю память выжирала и отваливалась

моя прошлая контора тоже на рид перешла в этом плане,а то доктрина на больших объемах всю память выжирала и отваливалась

кастомные гидраторы вас бы спасли)

они были =) ну там просто выборка 20-30к айтемов и ей сильно плохело

экстра лейзи и тд не спасало)

то есть 20-30К айтемов и потом вы делали еще и выборки по релейшенам?

ессно

ERROR: S client not available

=)

ну то есть N+1 запросов в базе?

кастомные гидраторы вас бы спасли)

отсутствие гидратора спасло бы

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

отсутствие гидратора спасло бы

увы приводить плоскую структуру в нетакую плоскую всеравно как-то надо

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

денормализация?

ну там изначально упарывались по ддд сильно))

Read Model построй себе и радуйся)

а запись?

а запись?

а что запись? приходит DTO на вход, а там дальше билдеры, сущности все как надо. Ни тебе геттеров ни сеттеров

максимум методы аля asId

ну там изначально упарывались по ддд сильно))

вот чисто для статистики, что есть упарываться по ddd?

а что запись? приходит DTO на вход, а там дальше билдеры, сущности все как надо. Ни тебе геттеров ни сеттеров

в итоге ты делаешь анемичную модель поверх своего домена

в итоге ты делаешь анемичную модель поверх своего домена

ээээээм.... с чего это? бизнес логики в моих сущностях хватает.

значит не имя базы знаний решили резко перейти на ДДД с МВЦ, на доктрину в полный рост и тд

в итоге ты делаешь анемичную модель поверх своего домена

ну то есть если следовать твоей логике то это не REST виноват, а это просто никогда у тебя не будет моделек без анемии

значит не имя базы знаний решили резко перейти на ДДД с МВЦ, на доктрину в полный рост и тд

что значит "на DDD с MVC"?))))

User -> UserDTO -> Rest resource -> UserDTO -> User

User -> UserDTO -> Rest resource -> UserDTO -> User

нет

UserProfileBuilder -> User::updateProfile

просто представь что у тебя нет UI)

нет REST или web

что значит "на DDD с MVC"?))))

значит были models, стали repositories\entities (doctrine)-> inside -< services как-то так

представь что у тебя есть соната

значит были models, стали repositories\entities (doctrine)-> inside -< services как-то так

это не ddd

представь что у тебя есть соната

не хочу)

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

или что у тебя есть фронт который делает таблички с формочками 1 в 1 как на базе

> или что у тебя есть фронт который делает таблички с формочками 1 в 1 как на базе ну так пусть прямо из базы и забирает

ему тут даже DTO не нужны, не говоря уже о промежуточном мэппинга не сущности

это не ddd

что есть ддд, на этот вопрос я уже 3й год внятно не могу получить ответ, вот чтоб если а и б - то ддд, если а без Б - то не ддд

что есть ддд, на этот вопрос я уже 3й год внятно не могу получить ответ, вот чтоб если а и б - то ддд, если а без Б - то не ддд

Domain Driven Design это способ уменьшения издержек на перевод требований в код

значит были models, стали repositories\entities (doctrine)-> inside -< services как-то так

вы просто логику из контроллеров размазали по сервисам и назвали это ддд