Laravel Правилная архитектура

[LONGMAN]

Привет

Пишем корпоративную CMS на ларе
Хотелось бы узнать у кого как организован код и каких пекиджов используете
На пример мы думали использовать doctrine orm но решили остатся на eloquent, он лучше интегрирован в фреимворке.

Ешё мы добавили две слой, services и repositories что бы потом код легче тестить. То есть создаётся один сервис класс для каждой операции, он проверяет права юзера на операцию, делает второстепенные валидации и если всё в порядке, визывается репозитория и он уже грузит/обновляет дата из/в дб вызивая в свою очеред eloquent.
Этот сервис класс визывается из контроллера (или комманды). Я за худые контроллеры

Что вы думаете об этом? Как вы делаете?

 

[AmdY]

посмотри asgard cms

 

[Alexey Mezenin]

Мне кажется копировать структуру и практики из CMS не стоит, ведь они изначально заточены под то, чтобы быть универсальными (модульность, репозитории). Зачем использовать репозитории в каком-то конкретном проекте? Неужели планируете в будущем отказаться от Eloquent и перейти на файловое хранилище (или что-то подобное)? Хочется худые контроллеры, можете хранить дата логику в моделях, именно такой путь проповедует Laravel.

А вообще, «правильной» архитектуры не существует.

 

[LONGMAN]

Мне кажется копировать структуру и практики из CMS не стоит, ведь они изначально заточены под то, чтобы быть универсальными (модульность, репозитории). Зачем использовать репозитории в каком-то конкретном проекте? Неужели планируете в будущем отказаться от Eloquent и перейти на файловое хранилище (или что-то подобное)? Хочется худые контроллеры, можете хранить дата логику в моделях, именно такой путь проповедует Laravel.

А вообще, «правильной» архитектуры не существует.

Как раз это не конкретный проект, а корпоративный cms.
Вазможно в будушем перейдём на Doctrine на пример, или propel. Можно хранить дата логику в моделях, но тогда модели станут очен толстые и трудно будет тестировать, имхо. К тому же, я думаю что проверять пермишены юзера на операцию это не ответственность модели

 

[Alexey Mezenin]

Как раз это не конкретный проект, а корпоративный cms.

Я говорил про "универсальные" CMS вроде October и Asgard. Они должны быть отвязаны от любого типа хранилища. Корпоративная CMS - это уже проект.

Вазможно в будушем перейдём на Doctrine на пример, или propel. Можно хранить дата логику в моделях, но тогда модели станут очен толстые и трудно будет тестировать, имхо. К тому же, я думаю что проверять пермишены юзера на операцию это не ответственность модели

Честно скажу, не понимаю зачем с Eloquent переходить на что-то еще (или с чего-то еще на Eloquent). Если действительно такое предвидите, то, конечно же, используйте репозиторий.

 

[AmdY]

@Alexey Mezenin В том то и дело, что корпоративная CMS это не бесплатный оупенсурс, который не несёт ответcтвенности за обратную совместимость и безопасность данных. Тебе через 5-10 лет надо будет накатывать апдейт, при этом думать как бы не сломать ни свой код, ни сторонние плагины которые подописывали клиенты, ни плагины которые они расширяли. Солому нужно подстилать везде.

@LONGMAN лучше бы вы взяли асгард, он как раз вырос из корпоативной cms и похоже ребятам нужна подмога, у них мало плагинов, но скорее всего они просто закрыты. Я смотрел октябрь дважды, там как раз с плагинами полный водпрес, их много, но качество и возможность модификаций никакущие.

 

[Alexey Mezenin]

@Alexey MezeninТебе через 5-10 лет надо будет накатывать апдейт

Но ведь далеко не всегда прям надо. И зависит от того, на что менять, если фреймворк тот же, то замена полутора deprecated методов Eloquent будет наименьшей проблемой. В любом случае замена сторонних пакетов станет главной проблемой, в куче пакетов нет обратной совместимости между Laravel 5 и Laravel 4.

@LONGMAN лучше бы вы взяли асгард, он как раз вырос из корпоативной cms и похоже ребятам нужна подмога, у них мало плагинов, но скорее всего они просто закрыты. Я смотрел октябрь дважды, там как раз с плагинами полный водпрес, их много, но качество и возможность модификаций никакущие.

Судя по давности коммитов, обе CMS заброшены.