Если проект небольшой то логика в модели самое то

Просто разные весовые категории: Yii - это массовый RAD фреймворк. Там важна простота и скорость. Ради этого можно забить на архитектуру. Он живёт почти вообще без SOLID и прочих штук. И там почти никто не знает про DIC, конструкторы, приватные поля, PSR и шаблонизаторы. Symfony и Zend - это, наоборот, самые навороченные энтерпрайз-решения для серьёзных проектов, где абсолютно всё сделано по SOLID и прочим принципам и лучшим архитектурным практикам. Laravel - промежуточный вариант, построенный на компонентах Symfony и своих с добавлением собственных упрощений. Там можно работать как в RAD-режиме с фасадами и CRUD-ами для простых проектов, так и как угодно заморачиваться для сложных. Поэтому в массовых Yii и Laravel в комплекте идёт простая ActiveRecord, а в специфичных уже какой-либо DataMapper. Но никто не мешает при желании подключить либо Doctrine в Laravel, либо Eloquent или Propel в Symfony.

Логика как раз и должна быть в "модели". Это в любом проекте самое то.

Если что крупнее то отдельные классы, но в конечном все крутится вокруг модели а не контроллеров

Логика как раз и должна быть в "модели". Это в любом проекте самое то.

Просто не все понимают, что такое "модель"

что-то мне кажется что в моделях логики быть не должно. Для чего тогда сервисы?

что-то мне кажется что в моделях логики быть не должно. Для чего тогда сервисы?

А в какой книге сказано что должен быть сервис?

Логика как раз и должна быть в "модели". Это в любом проекте самое то.

документация к laravel

документация к laravel

ребята, как создать связь категорий с товаром, тоесть есть у меня hasMany всех категорий и каждая из них может иметь товары как оформить такую связь?

Просто разные весовые категории: Yii - это массовый RAD фреймворк. Там важна простота и скорость. Ради этого можно забить на архитектуру. Он живёт почти вообще без SOLID и прочих штук. И там почти никто не знает про DIC, конструкторы, приватные поля, PSR и шаблонизаторы. Symfony и Zend - это, наоборот, самые навороченные энтерпрайз-решения для серьёзных проектов, где абсолютно всё сделано по SOLID и прочим принципам и лучшим архитектурным практикам. Laravel - промежуточный вариант, построенный на компонентах Symfony и своих с добавлением собственных упрощений. Там можно работать как в RAD-режиме с фасадами и CRUD-ами для простых проектов, так и как угодно заморачиваться для сложных. Поэтому в массовых Yii и Laravel в комплекте идёт простая ActiveRecord, а в специфичных уже какой-либо DataMapper. Но никто не мешает при желании подключить либо Doctrine в Laravel, либо Eloquent или Propel в Symfony.

А в какой книге сказано что должен быть сервис?

где-то в книгах фаулера

https://laravel.com/docs/5.6/container и чуть выше провайдеры

было бы интересно почитать

вообще его всего бы нужно читать

там не говорится о том что надо, там рассказывается о возможностях контейнера.

"A deep understanding of the Laravel service container is essential to building a powerful, large application, as well as for contributing to the Laravel core itself." Цитата явно намекает, что это важно для любого приложения

да я то читаю на сайте его статьи. Но я не видел чтобы там было сказано что если у тебя AR, то вся логика в сервисах

что-то мне кажется что в моделях логики быть не должно. Для чего тогда сервисы?

ар не ар. все равно бизнес логика там не должна быть

Просто разные весовые категории: Yii - это массовый RAD фреймворк. Там важна простота и скорость. Ради этого можно забить на архитектуру. Он живёт почти вообще без SOLID и прочих штук. И там почти никто не знает про DIC, конструкторы, приватные поля, PSR и шаблонизаторы. Symfony и Zend - это, наоборот, самые навороченные энтерпрайз-решения для серьёзных проектов, где абсолютно всё сделано по SOLID и прочим принципам и лучшим архитектурным практикам. Laravel - промежуточный вариант, построенный на компонентах Symfony и своих с добавлением собственных упрощений. Там можно работать как в RAD-режиме с фасадами и CRUD-ами для простых проектов, так и как угодно заморачиваться для сложных. Поэтому в массовых Yii и Laravel в комплекте идёт простая ActiveRecord, а в специфичных уже какой-либо DataMapper. Но никто не мешает при желании подключить либо Doctrine в Laravel, либо Eloquent или Propel в Symfony.

ар не ар. все равно бизнес логика там не должна быть

id не AI :D

почитать доку

Логика приложения - в сервисах приложения. Логика модели - в сервисах и сущностях модели.

в реальности хз как к такому прийти

PSR?

причем он здесь

стандартный логер, контейнер ...

этого не достаточно

запили интерфейсы тогда . и отдавай их

стандартный логер, контейнер ...

как можно очистить текст от тегов

ар не ар. все равно бизнес логика там не должна быть

забавно читать человека который вроде пытался делать на yii ddd

Принцип один и крайне прост: каждый должен заниматься своим делом. Логика сущности - в сущности. Логика проверки значения - в объекте значения. Логика взаимодействия сущностей для какого-то юзкейса приложения - в объекте юзкейса. Логика загрузки файлов - в загрузчике файлов. Логика отправки уведомлений - в объекте-рассыльщике. Логика генерации токенов - в генераторе токенов. А использовать AR только как набор полей вроде ассоциативного массива со связями и методом save() - это уже другой анемичный подход.

Принцип один и крайне прост: каждый должен заниматься своим делом. Логика сущности - в сущности. Логика проверки значения - в объекте значения. Логика взаимодействия сущностей для какого-то юзкейса приложения - в объекте юзкейса. Логика загрузки файлов - в загрузчике файлов. Логика отправки уведомлений - в объекте-рассыльщике. Логика генерации токенов - в генераторе токенов. А использовать AR только как набор полей вроде ассоциативного массива со связями и методом save() - это уже другой анемичный подход.

Ребят, как обявить связь Все уровни подкатегорий и их товары Хоть что это за отношение получается?

Категории - nested set. Товар - категория - many-to-many