@chebotarevp, серьёзный аргумент про мозги, а поконкретней? Спасибо

Во всяком осознал, что не стоит так делать)

Просто куча хелперов куда их девать хз, один выход создать класс Helper со стат. Методами

чем известен человек снявший этот видос?

Ребята, есть класс со статическимт методами, которые друг друга бывает вызывают через self::, мне не нравится, если я сделаю над классом просто function name() и буду их вызывать, но уже без префикса self::, какой вариант пооптимтзированней?)

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

@chebotarevp, серьёзный аргумент про мозги, а поконкретней? Спасибо

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

И моя производительность замедлится.

И вот когда в коде много странных и нелогичных мест, то очень неудобно разрабатывать.

Ага, вон оно что

Благодарю! Низкий Вам поклон, товарищи

Кстати, классы со статическими методами - это довольно-таки ФПшно

Благодарю! Низкий Вам поклон, товарищи

Обращайся ?

т.е. делец

уверен? Я так и не понял, в каком университете он профессор и почему ты так ухватился за этого человека игнорируя сотни других?

Ну когда ФПшники против ООПшников я еще понимаю. Но когда процедурщики против ООПшников то это смищно :D

Вовсе не ортогональны)

Мульпарадигменный вроде как

Но я в нём не разбираюсь)

Пхахаха

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

Соболезнуем Леше Бердникову @larakit https://www.facebook.com/larakit.ru

см ссылку на фб

всем привет, по ларавел подскжпите плз https://prnt.sc/noklru

фасад по алиасу не виидт

кажется в канале симфони спят, есть тут кто его знает? точне работа с несколькими серверами БД?

кажется в канале симфони спят, есть тут кто его знает? точне работа с несколькими серверами БД?

а по русски?

Полагаю он спрашивает, как подключить симфони к нескольким бд

Всем привет

Кто-то с api easypay.ua работал? Не могу авторизацию пройти, все время пишет неверный ключ, если эти данные через форму на сайте ввожу - все гуд

уже долго ищу в сети бест практику по созданию микросервиса авторизации. Допустим я юзаю доктрину в качестве орм для моей базы. У меня есть табличка users, в которой я храню login, password и email. Хочу сделать auth микросервис, который бы проверял на входе пару логин и пароль и если нашел это в базе, то возвращал бы некий токен. Отлично. Заводим модель User, описываем ентити, в микросервисе коннектимся к базе, генерируем токен и все супер. Но потом у меня появляется второй микросервис. В котором я хочу получать email пользователя из той же таблицы той же базы. Получается мне снова нужна модель и ентити доктрины уже во втором микросервисе? Как быть? Это же дублирование кода... а если сервисов, которые общаются с данными о пользователях целая куча? Помогите.. как кто делает?

а зачем ты хранишь там емейл, если у тебя логин?

но в целом - можно зашить емейл в токен (пейлоадс в jwt) или сделать метод апи в микросервисе аутентификации "дай информацию по юзеру"

а зачем ты хранишь там емейл, если у тебя логин?

это для примера. В целом таблица user очень большая с кучей информации по пользователю. И собственно от этого и проблема.. как мне теперь выделить микросервис авторизации из всего этого? По хорошему у мекросервиса же своя бд должна быть со своими данными. Мне в другом треде подсказали, что в таком виде авторизационный сервис работать не должен. И что для проверки логина и пароля он должен обратится в другой сервис, который имеет доступ к user базе данных

сервис с базой в которой логин и пароль

и вся остальная инфа по юзеру.. потому что какой сервис например должен осуществлять смену пользователем своего пароля? "auth" ? или сервис "user" ? Тут и получается, что если делать сервис auth с доступом к таблице с данными о пользователе, ( к его логину и паролю), то в другом сервисе тоже потребуется этот доступ, но к другим полям.. А если ко всей инфе о пользователе (включая логин и пароль) имеет доступ только сервис "user", то без общения между сервисами auth и user выходит что не обойтись... верно?

это для примера. В целом таблица user очень большая с кучей информации по пользователю. И собственно от этого и проблема.. как мне теперь выделить микросервис авторизации из всего этого? По хорошему у мекросервиса же своя бд должна быть со своими данными. Мне в другом треде подсказали, что в таком виде авторизационный сервис работать не должен. И что для проверки логина и пароля он должен обратится в другой сервис, который имеет доступ к user базе данных

Вроде правильно, но как-то попахивает микросервисным адом

Я бы сделал сервис аутентификации и всей инфы о пользователе. Там пользователь логинится на сайт. А когда заходит на другой сервис/сайт с токеном, то по токену вытаскивается вся необходимая инфа пользователя и сохраняется в сессии.

А можно не в сессии, а в таблице просто

Я бы сделал сервис аутентификации и всей инфы о пользователе. Там пользователь логинится на сайт. А когда заходит на другой сервис/сайт с токеном, то по токену вытаскивается вся необходимая инфа пользователя и сохраняется в сессии.

да, я примерно так же тоже мыслил.. но как то не понравилось, что auth сервис по сути превращается в таком виде в full user service.. как то это не правильно на мой взгляд.. Думал все проще, отправил сервису логин и пароль, тот глянул базу, если все верно, вернул токен (создал куку, сессию, не важно) и дальше с этим токеном ходишь по всем остальным сервиса. А на практике когда стал делать, вышло, что без дублирования сущности пользователя в коде при таком подходе никак.. хотелось в токен зашить роли пользователя, еще какую то инфу о нем.. а это значит что дублировать модель пользователя все же придется во всех сервисах которые с ним работают... или все же делать общение по api между микросервисами и делать на каждый пук свой сервис ( согласен, попахивает адом) хз... вроде сложилось в голове, а вроде и чувтвую что что то не так

ERROR: S client not available

нет понятия "вся инфа о пользователе", у каждого сервиса свой скоуп инфы

у сервиса аутентификации из этой инфы - только логин и пароль

нет понятия "вся инфа о пользователе", у каждого сервиса свой скоуп инфы

а если скоупы пересекаются?

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

Из 100500 полей тебе надо только ФИО допустим, и у тебя будет сущность user id + token + fio, маленькая моделька

а если скоупы пересекаются?

depends on или дублируешь или выносишь в отдельный сервис

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

Считай это не дублированием а кешом

Дублирование это звучит как будто есть в системе 2 источника правды, но это не так.

Дублирование это звучит как будто есть в системе 2 источника правды, но это не так.

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

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

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

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

ну да

спасибо парни, в многом пролили свет

сайты верстают с помощью html и css

Так вырази

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