OS
Size: a a a
2020 October 16
OS
как можно получить authenticated user id на foreign key
ЕП
OS
у меня user_id nullable, ну этот должен получит user_id, для показать его documents
ЕП
Ссылку выше дали на чат для начинающих
ЕП
И у тебя описка, documentUs
ЕП
И связь правильно назвать user а не users, одному юзеру ж принадлежит
SU
как вы решаете след задачу
есть компонента которая делает вещи, зависимости передаются через конструктор, пишутся тесты и тд
рано или поздно появляется задача которой нужна новая зависимость
передача ее черед конструктор влечет за собой тонну правок, тк приходится править кучу тестов добавлять моки хотя в рамках теста она не нужна
какие решения ?
1 продолжать также
2 есть желание передавать контейнер в констуктор, из плюсов что интерфейс всегда одинаковый с другой стороны неочевидно что надо этому классу
есть компонента которая делает вещи, зависимости передаются через конструктор, пишутся тесты и тд
рано или поздно появляется задача которой нужна новая зависимость
передача ее черед конструктор влечет за собой тонну правок, тк приходится править кучу тестов добавлять моки хотя в рамках теста она не нужна
какие решения ?
1 продолжать также
2 есть желание передавать контейнер в констуктор, из плюсов что интерфейс всегда одинаковый с другой стороны неочевидно что надо этому классу
Я думаю, продолжать править это идея точно хуже второй. Если запрашивать необходимые объекты из сервис-контейнера? Он везде доступен, а если в последствии класс потребуется заменить, замену можно произвести одной правкой в сервис-провайдере этого объекта.
ЕП
И есть метод Auth::id() для получения айдишника юзера
SU
как вы решаете след задачу
есть компонента которая делает вещи, зависимости передаются через конструктор, пишутся тесты и тд
рано или поздно появляется задача которой нужна новая зависимость
передача ее черед конструктор влечет за собой тонну правок, тк приходится править кучу тестов добавлять моки хотя в рамках теста она не нужна
какие решения ?
1 продолжать также
2 есть желание передавать контейнер в констуктор, из плюсов что интерфейс всегда одинаковый с другой стороны неочевидно что надо этому классу
есть компонента которая делает вещи, зависимости передаются через конструктор, пишутся тесты и тд
рано или поздно появляется задача которой нужна новая зависимость
передача ее черед конструктор влечет за собой тонну правок, тк приходится править кучу тестов добавлять моки хотя в рамках теста она не нужна
какие решения ?
1 продолжать также
2 есть желание передавать контейнер в констуктор, из плюсов что интерфейс всегда одинаковый с другой стороны неочевидно что надо этому классу
Или да, передавать контейнер, из которого можно запросить что нужно. Если классу ничего не надо, он не будет обращаться в контейнер. Это в любом случае лучше постоянных правок.
ЕП
И почему одна модель User а вторая Documents
D
И почему одна модель User а вторая Documents
так много вопросов и так мало ответов
ЕП
Меня поразило сколько можно сделать косяков в паре строк кода, когда в доке есть примеры всего
ЕП
Ух, хорошо что я не сижу в чате для новичков...
🎃
Ух, хорошо что я не сижу в чате для новичков...
Нервы бережёшь?
D
Ух, хорошо что я не сижу в чате для новичков...
"я думал,что достиг дна, пока мне не постучали снизу"
🎃
ЕП
Нервы бережёшь?
Естественно
zN
Привет.
Кто то делал систему тестирования на Ларавель? Или может, где то есть уже готовое. Хочу глянуть на структуру БД.
Тесты типо такие: вопрос и варианты ответов. В конце прохождения тестов - результат правильных ответов.
Кто то делал систему тестирования на Ларавель? Или может, где то есть уже готовое. Хочу глянуть на структуру БД.
Тесты типо такие: вопрос и варианты ответов. В конце прохождения тестов - результат правильных ответов.
SU
как вы решаете след задачу
есть компонента которая делает вещи, зависимости передаются через конструктор, пишутся тесты и тд
рано или поздно появляется задача которой нужна новая зависимость
передача ее черед конструктор влечет за собой тонну правок, тк приходится править кучу тестов добавлять моки хотя в рамках теста она не нужна
какие решения ?
1 продолжать также
2 есть желание передавать контейнер в констуктор, из плюсов что интерфейс всегда одинаковый с другой стороны неочевидно что надо этому классу
есть компонента которая делает вещи, зависимости передаются через конструктор, пишутся тесты и тд
рано или поздно появляется задача которой нужна новая зависимость
передача ее черед конструктор влечет за собой тонну правок, тк приходится править кучу тестов добавлять моки хотя в рамках теста она не нужна
какие решения ?
1 продолжать также
2 есть желание передавать контейнер в констуктор, из плюсов что интерфейс всегда одинаковый с другой стороны неочевидно что надо этому классу
в CMS которую я написал ещё до появления laravel, у меня была введена Factory, которая передавалась классам. Классы запрашивали из неё необходимые объекты. Правкой класса Factory, в его коде или через наследование можно было заменять объекты, например устаревший класс для работы с функциями mysql на класс работающий через PDO. Проблем в моих случаях никогда не возникало. Сервис контейнер Laravel по сути тоже самое.