Если честно то да, уже бьет по производительности. Писалось все слишком хаотично и это реальный MVP... )

уверен что получится лучше?)

и там есть getRoles

Так он говорит про ACL. А это про RBAC. То есть надо чтобы у каждого пользователя были свои конкретные наборы прав. Типа то может то не может. не привязанные к ролям. То есть прям список разрешений каждого юзера свой.

Так он говорит про ACL. А это про RBAC. То есть надо чтобы у каждого пользователя были свои конкретные наборы прав. Типа то может то не может. не привязанные к ролям. То есть прям список разрешений каждого юзера свой.

ну и это именно то что я и говорю - есть у юзера getRoles, он у каждого может возвращать что угодно

и тебе решать что именно

а RBAC в симфони есть из коробки

Ну по сути есть.

Но он возвращает таки Roles :)

Понятно что я могу все что угодно вернуть

Но он возвращает таки Roles :)

и?

А вот нет у меня например в системе понятия Roles

Все юзеры

POST_EDITOR - вот тебе роль позволяющая редактировать посты

А вот нет у меня например в системе понятия Roles

ну ты можешь назвать это Permission

Да я понимаю. :)

ну так о чем разговор.

А где-то там было написано, что симфони не парсит из коробки без префикса ROLE_

тебе не надо прописывать даже эти "роли" никуда - просто вернул и все

Это про что?

А где-то там было написано, что симфони не парсит из коробки без префикса ROLE_

вроде бы оно вообще ничего не парсит и проверяет как есть

во всяком случае с версии 2.6 и появления воутеров вообще никаких проблем небыло с организацией этого говна

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

Ну я понял тебя. Спасибо. Здравая идея.

Ребята, а примерно так норм ли делать: article_repository: class: AppBundle\Repository\ArticleRepository factory: 'entity_manager:getRepository' arguments: 'AppBundle:Article' ?

А еще кстати можно не через factory делать arguments: - "@=service('doctrine').getRepository('AppBundle:Article')"

Это какая версия SF?

Любая вроде как

Ну из последних

Я не могу точно сказать, когда это появилось

Смотрится как то страшно конечно

По-моему намного более чиабельно чем с фабрикой.

Но на самом деле раньше фабрика эта выглядела еще страшнее ))

Ребята, а примерно так норм ли делать: article_repository: class: AppBundle\Repository\ArticleRepository factory: 'entity_manager:getRepository' arguments: 'AppBundle:Article' ?

Например удобно для тестов. Мокать только репозиторий, а не менеджер и репозиторий. А так же удобно внедрять как зависимость. Еще можно отменить публичность доктриновского репозитория и сделать сервис независимого репозитория. Если кратко, то помоему так делать нужно)

привет всем. как вы относитесь к денормализации данных на уровне сущности (например, user->firstName, user->lastName, user->fullName) ?

Например удобно для тестов. Мокать только репозиторий, а не менеджер и репозиторий. А так же удобно внедрять как зависимость. Еще можно отменить публичность доктриновского репозитория и сделать сервис независимого репозитория. Если кратко, то помоему так делать нужно)

А что мешает замокать репозиторий в моем случае? :)

А что мешает замокать репозиторий в моем случае? :)

придется мокать и манажер

это нормально или лучше такого избегать?

Разве? :)

Зачем его мокать?

У меня в DI уходит репозиторий

Мокаешь. Дизейблишь конструктор и прописываешь, что методы возвращают

Нет, в этом случае тоже как я понимаю один, это два варианта одного и того же, дело вкуса

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

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

А ну это типа да, намного сложнее замокать.

А еще кстати можно не через factory делать arguments: - "@=service('doctrine').getRepository('AppBundle:Article')"

ну такое. фабрика лучше

ну такое. фабрика лучше

Идеологически или практически?

Потому что на практике преимуществ не вижу

привет всем. как вы относитесь к денормализации данных на уровне сущности (например, user->firstName, user->lastName, user->fullName) ?

А если у тебя отдельно фамилия, имя, отчество хранятся и + ко всем имеется метод getFullName

во-первых у тебя репос не всегда будет репосом доктрины. это может быть просто сервис, который принимает em себе во-вторых @article_repository и в 3.3 симфони @AppBundle\Repository\ArticleRepository куда проще писать, чем каждый раз делать экспрешен для особых любителей юзать контейнер в контроллерах тоже не очень удобно и придется как и раньше юзать doctrine get repository ну и я не уверен что IDE будет нормально поддерживать такие конструкции в плане поиска использований, выводить тип и тд

во-первых у тебя репос не всегда будет репосом доктрины. это может быть просто сервис, который принимает em себе во-вторых @article_repository и в 3.3 симфони @AppBundle\Repository\ArticleRepository куда проще писать, чем каждый раз делать экспрешен для особых любителей юзать контейнер в контроллерах тоже не очень удобно и придется как и раньше юзать doctrine get repository ну и я не уверен что IDE будет нормально поддерживать такие конструкции в плане поиска использований, выводить тип и тд

Согласен со всеми пунктами. И вместе с тем, скажи, как часто тебе приходилось вдруг менять БД, или ОРМ в проекте?

Вот хоть раз пришлось?

дело не в смене орм

Я за 10 лет ни разу такого не сделал.

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

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

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

да

Так может тогда это должен быть не репос а сервис лучше?

Отдельный

это может быть репос, с каким-то особым гидратором или еще чего

Ну я понял.

Спасибо. :)

А если у тебя отдельно фамилия, имя, отчество хранятся и + ко всем имеется метод getFullName

ну, хранятся отдельно, стоит ли добавлять поле fullName, для того чтобы сохранить полное имя в базе, или лучше получать его методом getFullName?

Так метод лучше.

Зачем дублировать данные.

Потом поддерживать соответствие

конечно же метод

а если нужен фильтр по полному имени в списке пользователей, например?

ERROR: S client not available

в мускуле можно конкатенацию делать)

строить его через concat в sql

а если логика сложнее, чем конкатенация?

а если нужен список пользователей, с показом полного имени?

мне сущности гидрировать придётся

это сложнее чем конкатенация?

нет, это другой момент

чтобы выполнить $user->getFullName()

хорошо, а хранение количества элементов в коллекции в отдельном поле - это нормально, или так тоже лучше не делать?

как вариант, можно всё через отдельную read model сделать, и обновлять её при обновлении юзера

все по ситуации нужно смотреть. где-то лучше метод, где-то лучше в preUpdate склеивать, а где-то вообще не юзать сущности

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

а то хранение кол-ва эелементов внезапно где-то поломается

да, норм вариант, отдельная read model

и не будешь знать когда это произошло

можно elastic

а эластик проигрывает по быстродействию mysql на простых запросах типа "select * from user" ?

Так не отдельно эластик а вместе с мускл :) Где такой простой - делай прямой мускл запрос :)

это понятно, а полностью перевести все чтение на эластик - это лишнее?

Я думаю, это неверно

почему?

Это как перевести все на хранение в Memcache :)

Эластик - это по своему принципу - кэш

то есть, данные могут потеряться?)

То есть, как мне кажется, он не должен быть единственным хранилищем данных

Ну он же создан чтобы полнотекстовый поиск обеспечивать.

Кэш - это такая штука, которую ты должен мочь в любой момент инвалидировать и перекэшировать.

так я могу

основной сторадж - sql бд

elasticsearch только для чтения

ну то есть вывести список юзеров, для этого использовать эластик

чем плохо?