в соседнем чате уже обсудили

я только в этом общаюсь про ООП

я б сказал что овер дохера воды там

Читали? https://habr.com/company/jugru/blog/419179/

очередная хуита с базвордами.

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

лучше уж почитать какой-нибудь clean code

clean code божественен

возможно там не так много полезной инфы, но читается зато конфетка

возможно там не так много полезной инфы, но читается зато конфетка

я имею ввиду в сравнении с более упоротыми книгами про рефакторинг etc

мне clean architecture понравилась

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

я имею ввиду в сравнении с более упоротыми книгами про рефакторинг etc

хз рефактринг фаулера тож маст рид

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

ну так дядя боб же, че ты ожидал?)

там даже альтернативные названия этим принципам придуманы были

ну и как бы... архитектура должна создавать ограничения что бы проще было соблюдать принципы)

хз рефактринг фаулера тож маст рид

но читается сложнооо

оч сухой научный стиль

А как иначе

хз рефактринг фаулера тож маст рид

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

оч сухой научный стиль

да ладно?

вам книжки про архитектуру с разукрашками надо?

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

вам книжки про архитектуру с разукрашками надо?

Покрасить граф в 5 цветов

да

с картинками

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

всем нравится)

А если серьезно, можно писать материал описывая какие то интересные примеры и т.д., и более... в авторском стиле, а не научно публицистическом

но это просто никому не вперлось

вон одна книжка вышла за N лет

Помню мен очень понравилось в одной статье как обяънялось что такое мультеплексирвоание запросов)

А если серьезно, можно писать материал описывая какие то интересные примеры и т.д., и более... в авторском стиле, а не научно публицистическом

это не продуктивно

:)

это не продуктивно

для автора?

для автора?

и для читателя. ты научишься делать один конкретный проект

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

и для читателя. ты научишься делать один конкретный проект

Ты не прав, все зависит от того что написано

Ты не прав, все зависит от того что написано

оно все it depends

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

заходило на ура

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

и никакой привязки к деталям не было

не, примеры нужны, но "проект разобрать в книжке" это херня

согласен

Привет! Мы с друзьями создали уютный и полезный чатик по БД для обсуждения разных вопросов возникающих при работе с любыми системами хранения и управления данными. В русском комьюнити существует не так уж много чатов на данную тематику, и, откровенно говоря атмосфера в них не соответствует нашим взглядам на то как должно выглядеть продуктивное, взаимоуважительное общение технарей в интернете. В чате приветсвуется обсуждения вопрсоов любых уровней, от нубских до rocketScience Если вам у нас понравилось, то поделитесь ссылкой с друзьями, которым будут интересны наши разговоры https://t.me/dbGeeks

А в этом чатике текст другой..

Здорова, бандиты! Мы с друзьями основали отличный чат по БД для дискусса разных вопросов возникающих при работе с любыми системами хранения и управления данными. В русском комьюнити нет нормального чата на эту тему(только 1 неудачный высер от чсвшных лузеров) . В чате приветсвуется обсуждения вопросов любых уровней, от нубских до rocketScience Если вам у нас понравилось, то поделитесь ссылкой с друзьями, которым будут интересны наши разговоры. СЛАВА БАЗАМ ДАННЫХ!!! https://t.me/dbGeeks

Там цу, видимо, чуть другая

Текущий авторизованный пользователь API относится к слою работы с базой данных или нет? Спрашиваю с целью, куда засунуть проверки ролей текущего пользователя, чтобы сократить объем выборки из таблиц (не все всем дозволено видеть, в отличие от админа).

Под слоем БД подразумевается обычные репозитории. Тут такой момент, что это вроде бы и бизнес логика, а вроде бы и нет. Правила на выборку довольно специфичные и относятся ко всем таблицам, где присутствует user_id. Привык ограничивать доступ к экшену контроллера еще на подходе, но вот тут попался нестандартный кейс. Если это положить в репозиторий, тогда получу дубликаты кода в каждом месте (в каждом репозитории), где надо применять эти проверки. Мест пока всего 3, а может быть больше. С другой стороны, если проверки положить в сервис, то прощай нормальное тестирование без запуска всего фреймворка с юзер-аутентификацией. ?

Под слоем БД подразумевается обычные репозитории. Тут такой момент, что это вроде бы и бизнес логика, а вроде бы и нет. Правила на выборку довольно специфичные и относятся ко всем таблицам, где присутствует user_id. Привык ограничивать доступ к экшену контроллера еще на подходе, но вот тут попался нестандартный кейс. Если это положить в репозиторий, тогда получу дубликаты кода в каждом месте (в каждом репозитории), где надо применять эти проверки. Мест пока всего 3, а может быть больше. С другой стороны, если проверки положить в сервис, то прощай нормальное тестирование без запуска всего фреймворка с юзер-аутентификацией. ?

в сервис, но туда просто передать юзера. не надо сервис связывать с системой аутентификации

getSomethingForThisUser(User $user, ...

Хм. Что тогда делать с одинаковыми запросами на выборку? Например, если у меня роль Агент, то я должен из пользователей выбрать самого агента и всего его клиентов в базе. То же самое касается и других таблиц, только там уже привязка не к id, а к user_id. Да и объект другой. Но логика выборки сохраняется.

ну такова судьба у тебя :) там наверняка можно подрефакторить, но сторого говоря это не копипаст. бизнес-требования такие. что в одном случае что в другом - просят и агента и всех его клиентов. в любой момент может поменяться.. в какомто случае надо будет просто агента.

Выходит, что в сервисе будут дубликаты кода. Т.к. сервис в себя принимает репозиторий и будет что-то типа: https://gist.github.com/roquie/8b1170f345e62a46480ab16d073642cf

я вот задумался. есть репозитория для write модели. get, persist, delete. а есть "репозитории" как у товарища этого. read репозитории. вы их тоже репозиториями кличете? или как-то по-другому?

А теперь прикинь вот это каждый раз повторять в каждом сервисе, в котором надо ограничить выборку: https://gist.github.com/roquie/8b1170f345e62a46480ab16d073642cf#file-example-php-L39

UserServiceInterface зачем тебе интерфейсы такие? :)

я вот задумался. есть репозитория для write модели. get, persist, delete. а есть "репозитории" как у товарища этого. read репозитории. вы их тоже репозиториями кличете? или как-то по-другому?

Можно это обозвать Storage’ом, т.к. если брать подход доктрины с его Unit of Work, то вообще ларавел можно выкинуть :))

Можно это обозвать Storage’ом, т.к. если брать подход доктрины с его Unit of Work, то вообще ларавел можно выкинуть :))

нет. storage - это как раз для хранилища. которое store данные. а мне бы название поудачнее для запросных вещей. Query - както слишком пассивно :)

UserServiceInterface зачем тебе интерфейсы такие? :)

опустим это ) это пример )

опустим это ) это пример )

но довольно важный пример

если у тебя есть UserService & UserServiceInterface разве может быть чтото еще реализующее этот интерфейс? это чтото еще будет каким-то... вторичным :)

ERROR: S client not available

ведь есть главный UserService...

нет. storage - это как раз для хранилища. которое store данные. а мне бы название поудачнее для запросных вещей. Query - както слишком пассивно :)

У меня репозитории, которые persist, умеющие в создание и обновление зависи. Есть еще более правильный подход, где этого нет. Но это не тот случай.

если у тебя есть UserService & UserServiceInterface разве может быть чтото еще реализующее этот интерфейс? это чтото еще будет каким-то... вторичным :)

У меня его пока нет. Интерфейс тут лишний да, других реализаций тута не будет, ибо несколько бизнес логик под одним интерфейсом в приложении не водятся.

ну такова судьба у тебя :) там наверняка можно подрефакторить, но сторого говоря это не копипаст. бизнес-требования такие. что в одном случае что в другом - просят и агента и всех его клиентов. в любой момент может поменяться.. в какомто случае надо будет просто агента.

ну это не оправдание для копипаста одного по смыслу функционала )

ну это не оправдание для копипаста одного по смыслу функционала )

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

методы будут одинаковые, а вот репозитории будут разные (если брать пример выше)

методы будут одинаковые, а вот репозитории будут разные (если брать пример выше)

значит и методы разные

представь что в одном из случаев бизнес оппросит немного по-другому сформировать запросы?

в таком случае, я уберу этот фильтр и реализую другой

в сервис, но туда просто передать юзера. не надо сервис связывать с системой аутентификации

Кстати, почему?

Это ведь относится и к репозиторию?

Кстати, почему?

сервис - это один слой. аутентификация - другой

представь что у тебя будет юзер console. и у тебя в консоли будут разные команды от его имени выполняться. там аутентификация совсем другая будет.

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

ага, верно

Это ведь относится и к репозиторию?

тогда ответ утвердительный? :)

ну вероятно в чате меня поправят этом... репозитории - тоже уже в другом слое лежат. в слое БД или просто инфраструктуры. там держать логику бизнесовую - весьма неправильно. там должны быть тупые методы по выдаче нужных данных.

Если ты реализуешь паттерн абстарктная фабрика, объекты которые он порождает должны знать друг о друге? Или это не обязательно?

Отчасти согласен. Но с другой стороны, это ведь тоже работа с БД. А работа с БД должна быть в отдельном слое полностью, а не частично. Что плохого в конструктор репозитория передать модель залогиненного юзера? :)

Отчасти согласен. Но с другой стороны, это ведь тоже работа с БД. А работа с БД должна быть в отдельном слое полностью, а не частично. Что плохого в конструктор репозитория передать модель залогиненного юзера? :)

нет. то что агенту надо отдавать такие данные а админу другие - это логика бизнесовая. это не логика БДшная

Отчасти согласен. Но с другой стороны, это ведь тоже работа с БД. А работа с БД должна быть в отдельном слое полностью, а не частично. Что плохого в конструктор репозитория передать модель залогиненного юзера? :)

не передавай в конструктор сервисов сущности. это 5ый смертный грех :)

не передавай в конструктор сервисов сущности. это 5ый смертный грех :)

почему

почему

а откуда они должны взяться?

хто?

сервисы и сущности?

сущность юзера

которую в сервис передадут

сущность юзера

$this->get('security.token_storage')->getToken()->getUser(); ??

если можно связать циклы жизни сервиса-сущности, то можно

$this->get('security.token_storage')->getToken()->getUser(); ??

я бы тебя забанил за ник и за совет, но ты тут еще и админ :)