Разве Eloquent это уже не уровень абстракции над базой данных? Если мы решим сменить драйвер к примеру с MySQL на PostreSQL, то разве сменяться такие методы как find, get, all, join, where? Возможно что-то поламаеться (сырые запросы, миграции, нестандартные ситуации), но репозиторый разве может помоч в даной ситуации?
Привет. А если допустим тебе надо выбрать из базы категории/подкатегории - сджойнить несколько таблиц - сделать меню, которое на сайте на всех страницах выводится. На нескольких видах страниц одно и то же меню. Ты же не будешь вызывать из всех контроллеров портянку запросов с where и join всякими - надо же куда-то вынести этот запрос на выборку для меню. Куда его вынести - в метод самой модели? Я думал, что репозитории и существуют для того, чтобы в них такое писать, разве нет?
Предупреждение для тех у кого память не очень), если вы решите пока просто помотреть участок где рассказывают и показывают "говнокод" и не писать его, а продолжить уже с правильным кодом, не делайте так) пишите все! Потом будет легче
@@DmitryAfanasyev ну так как я немного уже знаком с MVC и ларкой, то мне казалось что все очень просто, но в дальнейшем появились непонятки, и я опять убеждаюсь что пока не проделаешь сам - не запомнишь
Приветствую Дмитрий! Если найдётся немного времени, напиши пожалуйста команды - которыми ты создал Репозитории ! Необходимо добавить в composer.json что-то ? в ветку - - dev И выполнить какую-то команду по созданию php artisan make....... ?
Огромное спасибо за ответ! Но вот на ГитХабе есть следующее: composer require jason-guru/laravel-make-repository --dev и команда Артисана php artisan make:repository UserRepository Так лучше не делать?
Это не совсем то. Ты привел в пример некий чужеродный пакет для Ларавел. ЭТО СТОРОННИЙ ПАКЕТ. Как он работает и какие именно задачи выполняет - мне не ведомо. Ясно дело что скорее всего реализовывает паттерн Репозиторий - но какую именно интерпретацию - не знаю(и не интересно). В курсе этот пакет использоваться не будет.
Спасибо ещё раз огромное! Всё сделал руками и всё ок, здесь главное понять суть! Реализаций репозиториев несколько, нашёл в сети разные по методу реализации, но суть у них одна - быть прослойкой между логикой и хранилищем данных (не обязательно MySQL и другие)
Сказать честно, сперва не особо вкурил для чего нужны репозитории, но мне помогли примеры отсюда - vegibit.com/laravel-repository-pattern. А автору - огромное спасибо за уроки !
Может выскажусь раньше времени, я еще не смотрел остальные части. У меня были ситуации, когда репозитории были излишне, например проект простой и там всего пару строк очевидных было, но это занимало время что бы зайти в каждый реп, посмотреть че же оно там делает. Но были ситуации когда были всякие сайты знакомств. Были на mysql, а потом проект вырос и перенесли сразу на Postgres и пришлось все эти репозитории перелопатить, потому что не каждый фреймворк при смене базы начинает интерпретировать команды к базе как надо в данном случае Like и ILike и такой фигни очень много, в таком варианте ты не можешь просто сменить прослойку, все равно приходится переписывать. А потом вообще решили морду сменить на JS фрейм и давай, лупи мне АПИ под всё и опять переписывать и интерпретировать в JSON.
Для подавляющего большинства репозитории вообще оверхед, ихнужно использовать только тогда, когда точно знаешь зачем они нужны и понадобятся в дальнейшем. А если смена хранилища не потребуется, то все эти методы из видео нужно писать в модель, она для того и нужна.
@@DmitryAfanasyevФреймворки генерят уже сразу подобные методы в моделях или есть готовые надстройки в сервис локаторах(что в принципе антипатерн, но очень удобно). + почти все используют ленивую загрузку объектов и ORM(Doctrine) тянет информацию об Entity, но не делает агрегацаию в объекты. Это я к тому, что большинство обережет сам ORM. В любом случае, спасибо большое за уроки. Я много проектов больших доделывал на Symfony. Просто я слепо следовал документации не понимая зачем эти репозитории, слежения за объектами и т.д.
Очень плохая практика. Толстая модель получится (мега -жирная). В таком случае вообще всё можно в сразу в контроллере херачить - чё бы нет-то! А когда корабль начнет тонуть - уволиться к херам :DDDD
@@DmitryAfanasyevона и так толстая из-за связей, чего уж мелочится, я все что связано с одной моделькой и куере билдером выношу в скоуп, если несколько моделей, например мудреная форма, то сервис класс
Если оставаться в базовой архитектуре проекта, то да, будет толстый (но это лучше чем толстая модель!). И если использовать модульность, то репозитории будут тонкими.
@@DmitryAfanasyev А почему толстый репозиторий лучше толстой модели? Какая разница в модели куча кода или в репозитории тоже куча? Может лучше посмотреть по функциональности и разбить на несколько сервисов? Как я понимаю задача - не утонуть в коде? Я посмотрел ecomerce проект bagisto, там все на модули разбито и в репозиториях нет много кода, но там и в моделях его не много. И если все перенести в модели - явно не утонешь. Проблему горы кода решает модульность и при чем здесь репозитории не понятно? А чаще всего в проектах с репозиториями - пустые модели и толстые репозитории. И в этих репозиториях утонешь точно также как и в толстых моделях, если конечно в проекте действительно очень много кода.
Так он ничего плохого не написал. Не надо так остро реагировать. Ничего плохого в говнокод нет. Путь к хорошему коду лежит через тонны говнокода и никак иначе.
Репозиторий довольно приличный паттерн, все будет нормально если его использовать по назначению. А проблема 1000 репозиторий в одном проекте не является проблемой самого этого паттена, скорее это проблема кривых рук тимлида проекта, который не знает что такое микросервисная архитектура.
Eloquent - на прямую????? Что???? Слышали за DB, и то это не напрямую "Дублирование" - Eloquent это реализация репозитория, я вот никак не могу разобраться зачем велосипед? А почему не юзать Doctrine? Так вы и на неё запихнете костыли. Да я считаю это костыль - вот где то что то услышал. Расмотрим переход на другую БД - всё изменить, полностью всё... В чем выигрышь? Замена Eloquent на Doctrine - всё переделать, тоже полностью всё. Где плюсы?
Высокоэмоциональный комментарий. Общий посыл не ясен. Если постараться убрать эмоции и описать вопрос только сухой логикой, будет понятнее. Так-же лучше пересмотреть все эти видосы про репозиторий и видос, один из последних, про не верное использование моделей. Тогда, вероятно, и не было бы таких эмоций. В любом случае, благодарю за мнение 🙏👍
@@DmitryAfanasyev да, вы в дальнейшем выражаете мои мысли (по крайней мере во втором, третий еще не смотрел). А эмоции - присутствуют, просто везде требование работа через репозитории, не проблема, вот только смысл лишней логики не понятен. Код должен быть максимально чистым и прозрачным, а выходит нечто монстроозное, и совершенно не поворотное (если смотреть сервисы а не сайт аля лендинг)
Видео ни о чём, какая то вода, пол видео вообще заняло о том, что вы вероятно никогда не будете переходить на другую БД...хотя это чушь полная. Надеюсь следующие будут более информативными.
Всем привет. У одного человека подсмотрел способ получение обьекта по id. Например было: public function edit($id) { $item = $this->blogCategoryRepository->getEdit($id); if (empty($item)){ abort(404); } $categoryList = $this->blogCategoryRepository->getForComboBox(); return view('blog.admin.categories.edit', compact('item','categoryList')); } А можно этот же код написать как: public function edit(BlogCategory $category) { $item = $post; //лень было менять переменую во вьюхе с $item на $post $categoryList = $this->blogCategoryRepository->getForComboBox(); return view('blog.admin.posts.edit', compact('item','categoryList')); } Дмитрий хочется узнать ваше мнение по поводу данного способа.
Да, ларавел предоставляет такую магию, скорее всего я об этом упоминал, но несколько в ином контексте. По моему мнению такой способ можно избрать - в небольших проектах когда и кода мало и логики мало и надо быстро.
![Laravel урок №26: [ Что такое Репозиторий? #2 ]](http://i.ytimg.com/vi/_2nrUJtIsCo/mqdefault.jpg)
![Laravel урок №26: [ Что такое Репозиторий? #2 ]](/img/tr.png)
Это ПЕРВОЕ видео про репозитории. Видео получилось излишне продолжительным и по сему пришлось его порезать на 3(!) части.
За историю отдельное спасибо)
Нашлось свободное время, вернулся к Вашему курсу. Спасибо за уроки, продолжаем учиться!
3 видео "что такое репозиторий?", - это фундаментальный подход!
Еще раз спасибо! Все больше понимаю какую "дичь" я писал до ваших видео :)
Разве Eloquent это уже не уровень абстракции над базой данных? Если мы решим сменить драйвер к примеру с MySQL на PostreSQL, то разве сменяться такие методы как find, get, all, join, where?
Возможно что-то поламаеться (сырые запросы, миграции, нестандартные ситуации), но репозиторый разве может помоч в даной ситуации?
Да, так и есть.
Репозиторий тут имеет иную цель.
Спасибо! Все четко и понятно.)
Еще 2 видео в продолжении этой темы
Честно говоря так и не понял, чем удобнее после репозитория юзать where() и т.д. и чем это поможет при смене DB
Привет. А если допустим тебе надо выбрать из базы категории/подкатегории - сджойнить несколько таблиц - сделать меню, которое на сайте на всех страницах выводится. На нескольких видах страниц одно и то же меню. Ты же не будешь вызывать из всех контроллеров портянку запросов с where и join всякими - надо же куда-то вынести этот запрос на выборку для меню. Куда его вынести - в метод самой модели? Я думал, что репозитории и существуют для того, чтобы в них такое писать, разве нет?
Операции чтении может быть сколько угодно, потому что они стейт приложения не модифицируют
Подобные вещи будут рассмотрены в курсе. Решения есть.
для такого случая с меню есть view composer
В Сервис провадер можно вынести, например в АппСервис провадер метод бут. типа так \View::share('var', $var);
@@DmitryAfanasyev конечно есть - репозиторий)
Спасибо!
Блин, ты такой крутой, спасибо тебе.
Спасибо, супер!
Спасибо огромное!
паа почему не методы в модели ? в чем отличия ?
Не понял вопрос
Предупреждение для тех у кого память не очень), если вы решите пока просто помотреть участок где рассказывают и показывают "говнокод" и не писать его, а продолжить уже с правильным кодом, не делайте так) пишите все! Потом будет легче
А ты пропускал? 😀
@@DmitryAfanasyev ну так как я немного уже знаком с MVC и ларкой, то мне казалось что все очень просто, но в дальнейшем появились непонятки, и я опять убеждаюсь что пока не проделаешь сам - не запомнишь
Зачет!!!! Классно
Что такое сэптимы? Интересное слово
Основная валюта Тамриэля
@@DmitryAfanasyev спасибо, буду знать)
Приветствую Дмитрий!
Если найдётся немного времени, напиши пожалуйста команды - которыми ты создал Репозитории !
Необходимо добавить в composer.json что-то ? в ветку - - dev
И выполнить какую-то команду по созданию php artisan make....... ?
Руками создавал... Всё в видео. Ничего не вырезано. В ларе нет команды для создания репозитория. И понятия такого нет.
Огромное спасибо за ответ!
Но вот на ГитХабе есть следующее:
composer require jason-guru/laravel-make-repository --dev
и команда Артисана
php artisan make:repository UserRepository
Так лучше не делать?
Это не совсем то. Ты привел в пример некий чужеродный пакет для Ларавел. ЭТО СТОРОННИЙ ПАКЕТ. Как он работает и какие именно задачи выполняет - мне не ведомо. Ясно дело что скорее всего реализовывает паттерн Репозиторий - но какую именно интерпретацию - не знаю(и не интересно). В курсе этот пакет использоваться не будет.
Спасибо ещё раз огромное!
Всё сделал руками и всё ок, здесь главное понять суть! Реализаций репозиториев несколько, нашёл в сети разные по методу реализации, но суть у них одна - быть прослойкой между логикой и хранилищем данных (не обязательно MySQL и другие)
"а может быть ноль?!" - смешно было)
Thanks!
Елисеевский подход или собственный?
Не знаком с Елисеевским подходом. Впервые слышу.
Так ничего толком и не обьяснил.
Это первое видео, впереди еще два... В описании же написано....
если бы можно было свентить с подобия орм Eloquent , на что то вроде Django было бы круто. А то задолбало SQL запросы писать и редачить
Уволили того разработчика или оставили?))
10:58 ставим скорость 2х 😂
Сказать честно, сперва не особо вкурил для чего нужны репозитории, но мне помогли примеры отсюда - vegibit.com/laravel-repository-pattern. А автору - огромное спасибо за уроки !
Спасибо
Иногда это не от тебя зависит, заказчику просто пришло в голову пересесть с MySQL на PostgreSQL, и всё -- сиди пересаживай))))
Может выскажусь раньше времени, я еще не смотрел остальные части. У меня были ситуации, когда репозитории были излишне, например проект простой и там всего пару строк очевидных было, но это занимало время что бы зайти в каждый реп, посмотреть че же оно там делает.
Но были ситуации когда были всякие сайты знакомств. Были на mysql, а потом проект вырос и перенесли сразу на Postgres и пришлось все эти репозитории перелопатить, потому что не каждый фреймворк при смене базы начинает интерпретировать команды к базе как надо в данном случае Like и ILike и такой фигни очень много, в таком варианте ты не можешь просто сменить прослойку, все равно приходится переписывать. А потом вообще решили морду сменить на JS фрейм и давай, лупи мне АПИ под всё и опять переписывать и интерпретировать в JSON.
Для подавляющего большинства репозитории вообще оверхед, ихнужно использовать только тогда, когда точно знаешь зачем они нужны и понадобятся в дальнейшем. А если смена хранилища не потребуется, то все эти методы из видео нужно писать в модель, она для того и нужна.
В модель эти методы можно писать исключительно если проект ооочень маленький. Ну прям совсем малюсенький. Иначе будут модели монсты....
@@DmitryAfanasyevФреймворки генерят уже сразу подобные методы в моделях или есть готовые надстройки в сервис локаторах(что в принципе антипатерн, но очень удобно). + почти все используют ленивую загрузку объектов и ORM(Doctrine) тянет информацию об Entity, но не делает агрегацаию в объекты. Это я к тому, что большинство обережет сам ORM.
В любом случае, спасибо большое за уроки. Я много проектов больших доделывал на Symfony. Просто я слепо следовал документации не понимая зачем эти репозитории, слежения за объектами и т.д.
Вместо репо можно использовать скоп в модели и все, любую логику прописать, модель и есть репо
Очень плохая практика. Толстая модель получится (мега -жирная). В таком случае вообще всё можно в сразу в контроллере херачить - чё бы нет-то! А когда корабль начнет тонуть - уволиться к херам :DDDD
@@DmitryAfanasyevона и так толстая из-за связей, чего уж мелочится, я все что связано с одной моделькой и куере билдером выношу в скоуп, если несколько моделей, например мудреная форма, то сервис класс
@@DmitryAfanasyev А репозиторий тонкий получится? Какая разница толстый репозиторий или толстая модель? Или у Вас много репозиториев к одной модели?
Если оставаться в базовой архитектуре проекта, то да, будет толстый (но это лучше чем толстая модель!). И если использовать модульность, то репозитории будут тонкими.
@@DmitryAfanasyev А почему толстый репозиторий лучше толстой модели? Какая разница в модели куча кода или в репозитории тоже куча? Может лучше посмотреть по функциональности и разбить на несколько сервисов? Как я понимаю задача - не утонуть в коде? Я посмотрел ecomerce проект bagisto, там все на модули разбито и в репозиториях нет много кода, но там и в моделях его не много. И если все перенести в модели - явно не утонешь. Проблему горы кода решает модульность и при чем здесь репозитории не понятно? А чаще всего в проектах с репозиториями - пустые модели и толстые репозитории. И в этих репозиториях утонешь точно также как и в толстых моделях, если конечно в проекте действительно очень много кода.
хуже всего когда начинающий пытается писать проект по фэншую. такой шизокод получается !!! спс за видео
Так он ничего плохого не написал. Не надо так остро реагировать. Ничего плохого в говнокод нет. Путь к хорошему коду лежит через тонны говнокода и никак иначе.
Вхэре)))
Репозиторий довольно приличный паттерн, все будет нормально если его использовать по назначению. А проблема 1000 репозиторий в одном проекте не является проблемой самого этого паттена, скорее это проблема кривых рук тимлида проекта, который не знает что такое микросервисная архитектура.
Не спеши с выводами - впереди ещё 2 видео о репозиториях.
Eloquent - на прямую????? Что????
Слышали за DB, и то это не напрямую
"Дублирование" - Eloquent это реализация репозитория, я вот никак не могу разобраться зачем велосипед? А почему не юзать Doctrine? Так вы и на неё запихнете костыли. Да я считаю это костыль - вот где то что то услышал.
Расмотрим переход на другую БД - всё изменить, полностью всё... В чем выигрышь?
Замена Eloquent на Doctrine - всё переделать, тоже полностью всё. Где плюсы?
Высокоэмоциональный комментарий. Общий посыл не ясен. Если постараться убрать эмоции и описать вопрос только сухой логикой, будет понятнее. Так-же лучше пересмотреть все эти видосы про репозиторий и видос, один из последних, про не верное использование моделей. Тогда, вероятно, и не было бы таких эмоций. В любом случае, благодарю за мнение 🙏👍
@@DmitryAfanasyev да, вы в дальнейшем выражаете мои мысли (по крайней мере во втором, третий еще не смотрел). А эмоции - присутствуют, просто везде требование работа через репозитории, не проблема, вот только смысл лишней логики не понятен. Код должен быть максимально чистым и прозрачным, а выходит нечто монстроозное, и совершенно не поворотное (если смотреть сервисы а не сайт аля лендинг)
видео хороши в хере 😁
В}{ере да?😅
как можно растянуть объяснение на 13 минут и все равно не понятно рассказать? индусы к сожалению лучше рассказали.
Так иди к индусам )))
3 части не о чем. норм инфы тут не найдете.
чел снимает видос про репозитории и даже не удосужился открыть файл с реализацией репозитория
Видео ни о чём, какая то вода, пол видео вообще заняло о том, что вы вероятно никогда не будете переходить на другую БД...хотя это чушь полная. Надеюсь следующие будут более информативными.
Всем привет. У одного человека подсмотрел способ получение обьекта по id.
Например было:
public function edit($id)
{
$item = $this->blogCategoryRepository->getEdit($id);
if (empty($item)){
abort(404);
}
$categoryList = $this->blogCategoryRepository->getForComboBox();
return view('blog.admin.categories.edit', compact('item','categoryList'));
}
А можно этот же код написать как:
public function edit(BlogCategory $category)
{
$item = $post; //лень было менять переменую во вьюхе с $item на $post
$categoryList = $this->blogCategoryRepository->getForComboBox();
return view('blog.admin.posts.edit', compact('item','categoryList'));
}
Дмитрий хочется узнать ваше мнение по поводу данного способа.
Да, ларавел предоставляет такую магию, скорее всего я об этом упоминал, но несколько в ином контексте. По моему мнению такой способ можно избрать - в небольших проектах когда и кода мало и логики мало и надо быстро.
вхере
😎
Спасибо
Спасибо