Правильно - ты в каком смысле?

Правильно т.е. в соответствии с тем, что рассказывают в уроках в начале о MVC. Т.е. реализовывать подобное в моделях, для чего они, как я понял и предназначены. Я не могу чет въехать в это. Есть вариант создать отдельный класс для валидации, но тогда я не понимаю зачем нужна модель, кроме как ссылки на таблицу в БД

Исходи из того, что каждый класс выполняет только одну функцию

Модель тебе предоставляет доступ к данным

Модель это объект или данные с которыми ты оперируешь, они не обязательно хранятся в БД

Блин, начал писать, а все написали) Удобно

Ну так манипуляции с данными тоже должны происходить в моделях или нет?

Нет

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

Посмотри что такое SOLID

Правильно т.е. в соответствии с тем, что рассказывают в уроках в начале о MVC. Т.е. реализовывать подобное в моделях, для чего они, как я понял и предназначены. Я не могу чет въехать в это. Есть вариант создать отдельный класс для валидации, но тогда я не понимаю зачем нужна модель, кроме как ссылки на таблицу в БД

Изначально в классическом варианте MVC вся логика, как и работа с БД должна быть в модели, контроллер выступает только связующим звеном. В ВЕБе контроллер стал содержать в себе всю логику, в модели методы для работы с БД (как, например, в codeigniter), в таких фреймворках, как yii/laravel и методы для работы с БД перенесли в контроллер, классы модели бывают вообще пустыми. Но не всегда. Поэтому в ларе в основном, вся логика у тебя в контроллере, валидация и т.п., также у тебя запросы к БД, например, с помощью query builder у тебя тоже в контроллере, но внутри фреймворка, в его ядре, все эти запросы проходят через модели, даже если они пустые. В двух словах как-то так

Посмотри что такое SOLID

да, солид это то что ему нужно

кек

Изначально в классическом варианте MVC вся логика, как и работа с БД должна быть в модели, контроллер выступает только связующим звеном. В ВЕБе контроллер стал содержать в себе всю логику, в модели методы для работы с БД (как, например, в codeigniter), в таких фреймворках, как yii/laravel и методы для работы с БД перенесли в контроллер, классы модели бывают вообще пустыми. Но не всегда. Поэтому в ларе в основном, вся логика у тебя в контроллере, валидация и т.п., также у тебя запросы к БД, например, с помощью query builder у тебя тоже в контроллере, но внутри фреймворка, в его ядре, все эти запросы проходят через модели, даже если они пустые. В двух словах как-то так

каком еще вебе?

Изначально в классическом варианте MVC вся логика, как и работа с БД должна быть в модели, контроллер выступает только связующим звеном. В ВЕБе контроллер стал содержать в себе всю логику, в модели методы для работы с БД (как, например, в codeigniter), в таких фреймворках, как yii/laravel и методы для работы с БД перенесли в контроллер, классы модели бывают вообще пустыми. Но не всегда. Поэтому в ларе в основном, вся логика у тебя в контроллере, валидация и т.п., также у тебя запросы к БД, например, с помощью query builder у тебя тоже в контроллере, но внутри фреймворка, в его ядре, все эти запросы проходят через модели, даже если они пустые. В двух словах как-то так

Добра тебе

веб не ограничивается mvc

почему вы путаете людей, это моя должность

В mvc вебе, mvc то придумали ещё в 70-х

отнимать работу нехорошо

почему вы путаете людей, это моя должность

вот это хорошо было)

(з.ы. а в ларке не MVC, а MVCS)

а что S значит? я правд не знаю

пойду погуглю

service

ну, по крайней мере это хорошая практика, юзать ларавел как MVCS

даже коробочный функционал с таким подходом написан

Угу, загуглил.

мне зашло

удобная либа

маладэц

Что это за exit у тебя там? О_о

Да и else тут лишнее, если местами блоки поменять и в условие ! добавить

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

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

лучше разберись с ларавелевским

заодно посмотришь на красивый код)

Что это за exit у тебя там? О_о

А чего нет? else для наглядности и читабельности - зачем мне отрицания строить?

exit - заглушка

Написать проще, чем использовать втроенный - означает, что ты даж 5 мин не потратил на его изучение)

А этого времени (ну примерно) хватает на то, чтобы понять, как там все просто)

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

Конечно разберись, зато раз разберёшься и будешь применять во всех проектах

exit - заглушка

Завершать выполнение exit (die) не стоит. Есть свои обычные стредства. Бросай исключение, возвращай response() нужный

солидарен

А этого времени (ну примерно) хватает на то, чтобы понять, как там все просто)

в доке статья, которую больше 5ти минут читать. Плюс там как я понял имеются требования к БД. Реализован механизм редиректа на страницу авторизации, если не авторизован, + мне необходимо разделение по ролям. Как это все всунуть во встроенный я за 5 мин не пойму

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

в доке статья, которую больше 5ти минут читать. Плюс там как я понял имеются требования к БД. Реализован механизм редиректа на страницу авторизации, если не авторизован, + мне необходимо разделение по ролям. Как это все всунуть во встроенный я за 5 мин не пойму

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

что бы не говнокодить

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

А чего нет? else для наглядности и читабельности - зачем мне отрицания строить?

Посмотри на пример. Какой понятнее и чище?

тот который без exit() :D

в доке статья, которую больше 5ти минут читать. Плюс там как я понял имеются требования к БД. Реализован механизм редиректа на страницу авторизации, если не авторизован, + мне необходимо разделение по ролям. Как это все всунуть во встроенный я за 5 мин не пойму

Я бы советовал не торопиться. Ну в смысле не жалеть 5-10-500 минут на изучение инструмента, с которым работать планируешь не один раз

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

@negasus ты согласен со мной насчет MVCS то?

тот который без exit() :D

Ну это пример в вакууме же

Я бы советовал не торопиться. Ну в смысле не жалеть 5-10-500 минут на изучение инструмента, с которым работать планируешь не один раз

ну ок, спасибо за советы

@negasus ты согласен со мной насчет MVCS то?

Я сторонник того, чтобы в контроллере было минимум кода. Я все, что могу в сервисы выбрасываю, да

можно структуру как-нибудь увидеть?

структура тривиальна: 1) таблица категорий (id, название) 2) таблица тегов (id, название) 3) таблица постов (id, заголовок, контент) 4) pivot таблица для связи постов с тегами (post_id, tag_id) надо в модели категории получить список всех тегов

Я сторонник того, чтобы в контроллере было минимум кода. Я все, что могу в сервисы выбрасываю, да

??

структура тривиальна: 1) таблица категорий (id, название) 2) таблица тегов (id, название) 3) таблица постов (id, заголовок, контент) 4) pivot таблица для связи постов с тегами (post_id, tag_id) надо в модели категории получить список всех тегов

т.е. у тебя уже две таблицы отношений будет

да, hasManyThrough не подходит

т.е. посты относятся к категориям, а теги к постам?

у поста есть category_id

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

нет, разный

ERROR: S client not available

эээ

тогда причем тут разделы вообще

разделы не причем

структура тривиальна: 1) таблица категорий (id, название) 2) таблица тегов (id, название) 3) таблица постов (id, заголовок, контент) 4) pivot таблица для связи постов с тегами (post_id, tag_id) надо в модели категории получить список всех тегов

вот структура

есть категрия, в которой несколько постов.

у каждого поста несколько тегов через pivot-таблицу

если брать пример из доков: https://laravel.com/docs/5.4/eloquent-relationships#has-many-through в моем случае пользователь привязан к нескольким странам через таблицу

а не через поле country_id

не так))

у постов несколько пользователей

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

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

да

Пост относится к одной категии, или может в нескольких состоять?

к одной

Да, сходу оно работает только с однонаправленной связкой вроде

потестил. так как самому интересно, еще не трогал этот релейшн

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

вот-вот)) тут либо писать свой релейшн, либо в нужном месте собирать массив

А задача это получать - частая? Ну допустим, во фронте это видно постоянно, да?

нет, не частая

но мне тоже интересно как бы это сделать через отношения

даже со стороны производительности - чистый sql был бы быстрее

ща ковыряюсь, интересно

могу скинуть дамп бд с данными, если поможет))

но я так понял что в релейшн нет связи через 2 таблицы

я уж все перебробовал)

сек

select * from tags as t left join post_tag as pivot on pivot.tag_id = t.id and pivot.post_id in (select id from posts where category_id = 1) where pivot.tag_id is not null

Вот как то так

Блин, некрасиво без подстветки

Одним запросом все достаем, только id категории указываем