Как лучше организовать структуру сайта?

[Vodazar]

в Yii2 ввели новую структуру frontend/backend. Лично я так и не догоняю в чём фишка и потому прошу у вас помощи.

У меня система где есть публичная часть сайта, которая выводит контент.
Есть регистрация, после которой у зарегистрированного пользователя появляется личный кабинет и он там может что-то сделать.
А так же есть административная панель, в которой администратор сайта может изменять какие-либо настройки и добавлять контент.
К этому добавляется специальная группа пользователей, например "модераторы", у которой также есть свой "кабинет модератора".
И есть ещё 4 подобных кабинета, в которых пользователи:
а. работают с разными сущностями;
б. могут работать с одними сущностями, но имеют доступ к разным свойствам.
при этом у каждого пользователя есть доступ к личному кабинету, а у некоторых может быть доступ к дополнительным кабинетам.

Объясните пожалуйста, как в такой ситуации разруливать? Что backend, а что frontend?

p.s. в Yii1 я это разрулил просто через модули, с собственными наборами контроллеров, доступ к которым определялся ролью пользователя. Единственная проблема была это дублирование функционала (например если в разных кабинетах можно редактировать профиль пользователя (или любую другую одинаковую сущность)). Но как мне кажется и тут не будет золотой пули и надо ставить Basic приложение и пилить напильником всё в frontend/web папке.

[zelenin]

если вам нужно сделать личный кабинет внутри "морды" сайта, то делаете во фронтэнде.
если вам нужно делать личные кабинеты/кабинеты модераторов/администраторов с отдельным дизайном, делайте отдельными приложениями frontend/moderator/panel/backend, либо все в backend с хорошо настроенный rbac.

[Vodazar]

Ну дизайн отличается у публичной части и у кабинетов. Но это же не значит что кабинет пользователя (в котором он редактирует свой профиль) нужно делать в backend'e. Мне кажется тут должно быть какое-то более серьёзное обоснование для разделения. Для смены дизайна есть layout'ы. Или я что-то не правильно понимаю?

Пока получается backend это шибко надуманная необходимость скорее для каких-то систем с чётким разделением на группу пользователей и группу администраторов. И админ-панель делается в папочке backend и как-то дополнительно защищена или фиг его знает зачем ещё используется?

p.s. В целом мне кажется глупым деление серверного кода на front-end и back-end. Как-то это противоречит класическому деление клиент-серверных приложений на front-end и back-end...

[zelenin]

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

[Vodazar]

Итак, отказался от advanced шаблона приложения. Решил использовать Basic.

Но проблема осталась. Прошу помочь выбрать правильное направление решения задачи:
1. У нас есть модель User с полями: name, password, email, state, role
2. У нас есть кабинет пользователя /cabinet/ в котором пользователь может изменить данные своего профиля: name, password
3. У нас есть кабинет модератора, /moderator/ в котором модератор может изменить данные любого пользователя: name, password, email, state
4. У нас есть кабинет админитстратора, /admin/ в котором администратор может изменить любые данные любого пользователя.
5. Есть ещё 5 подобных кабинетов.

Решения:
1. Использовать модули 1 модуль = 1 кабинет, в модуле указываем доступ только для одной роли.
Проблема в том, что нам тогда нужно дублировать контроллеры для редактирования профиля пользователя. А также создавать представление формы для каждого из кабинетов.
modules/cabinet/profile/index
modules/moderator/users/update/123
modules/admin/users/update/123

2. Использовать модули 1 модуль = 1 сущность
Получаем единственный модуль, который можно заменить на другой модуль или отказаться от его использования отключив в одном месте.
modules/users/profile/update
Встаёт проблема с разделением прав. Пользователи могут редактировать одно, модераторы другое, админы третье.
Получается надо делать разные экшены в одном контролере по количеству ролей?
modules/users/default/adminUpdate/123
modules/users/default/moderatorUpdate/123
Или через разные роуты
modules/users/cabinet/update
modules/users/admin/update/123
modules/users/moderator/update/123
Но тогда тоже неудобно, экшены или контроллеры жёстко связаны с системой ролей. При этом не понятно, нужно ли импользовать разные модели? Или сценарии в модели? А представления для формы? А как объединить потом разрозненные модули в один кабинет?

3. В предыдущей схеме с модулями можно ещё настроить доступ через RBAC, но тогда получается надо делать rule на каждую роль для update? А как изменять набор изменяемых полей в зависимости от текущей роли пользователя?

Заранее спасибо, кто прочитал эту портянку двойное спасибо, если ответите!

[zelenin]

надо делать в advanced структуре, а basic оставить для сайтов без авторизации.

[Vodazar]

надо делать в advanced структуре, а basic оставить для сайтов без авторизации.

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

[zelenin]

надо делать в advanced структуре, а basic оставить для сайтов без авторизации.

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

легче разбить по нескольким приложениям

[chesar]

1. У нас есть модель User с полями: name, password, email, state, role
2. У нас есть кабинет пользователя /cabinet/ в котором пользователь может изменить данные своего профиля: name, password
3. У нас есть кабинет модератора, /moderator/ в котором модератор может изменить данные любого пользователя: name, password, email, state
4. У нас есть кабинет админитстратора, /admin/ в котором администратор может изменить любые данные любого пользователя.
5. Есть ещё 5 подобных кабинетов.

Я бы так попробовал:

Код: Выделить всё

//Редактирование профиля
public actionProfile($id=null){
  //пользователь не может редактировать чужие профили или выбран его профиль
  if($id===null || !\Yii::$app->user->can('updateProfileModerator')) {
    $id = \Yii::$app->user->id;
  } 
  $model = User::findByPk($id);
  if ( isset($_POST['User']) ) {
    //разрешаем сохранять только те данные на которые есть права
    $model->name = $_POST['name'];
    if(\Yii::$app->user->can('updateProfileModerator')) {
       $model->email = $_POST['email'];
    }
    if(\Yii::$app->user->can('updateProfileAdmin') {
      $model->status = USER::STATUS_BANNED;
    }
    $model->save();
  }
...
}

Ну и во вьюшке проверяем возможности, и в зависимости от этого выводим необходимые поля. Если вьюшки сложные со своими скриптами и js-плагинами, то делаем разные вью, и рендерим необходимую (а там для каждой свой набор ассетов подключается)

[chesar]

А по структуре, меня пока basic устраивает. Возможно конечно не прилетало ничего сверх естественного, но для порталов средней руки - достаточно. Всё лежит в модулях, в app\ ни контроллеров, ни вью, ничего нет.
Advanced будет удобен для мультисайтовости, для серьезных crm с кучей сервисов.

[zelenin]

А по структуре, меня пока basic устраивает. Возможно конечно не прилетало ничего сверх естественного, но для порталов средней руки - достаточно. Всё лежит в модулях, в app\ ни контроллеров, ни вью, ничего нет.
Advanced будет удобен для мультисайтовости, для серьезных crm с кучей сервисов.

совершенно неверные мысли.

[Vodazar]

zelenin, у вас крайне аргументированные сообщения спасибо, что тратите время на жалких людишек, черкнув 2-3 слова

[zelenin]

zelenin, у вас крайне аргументированные сообщения спасибо, что тратите время на жалких людишек, черкнув 2-3 слова

а что тут аргументировать? очевидно, что ваши аргументы за basic, могут быть также приписаны к advanced, а поэтому не являются аргументами, обосновывающими ваш выбор. Выбор вы сделали странный, учитывая задачу, стоящую перед вами.

ой, я вас спутал с chezar. Тем не менее свое мнение я уже высказал в рамках темы, а аргументировать неправильность религиозного выбора глупо.

[astronin]

смотрите, тут все просто
если вам надо разграничивать логику в глобальном смысле, админки от другого сайта и при этом у вас еще и будет дофига кронов, то лучше использовать advanced
если особой разницы нету между админкой, сайтом и кабинетами, т.е. почти все тоже самое, то можно обойтись и basic

[zelenin]

смотрите, тут все просто
если вам надо разграничивать логику в глобальном смысле, админки от другого сайта и при этом у вас еще и будет дофига кронов, то лучше использовать advanced
если особой разницы нету между админкой, сайтом и кабинетами, т.е. почти все тоже самое, то можно обойтись и basic

да какие админки от какого другого сайта? Причем тут кроны? Какая разница, если все консольные команды будут лежать в одной папке?

Если нужно логически разделять на части - это advanced. Если не нужно - basic.

[astronin]

вообще-то я об этом и написал... перечитайте плиз еще раз

[zelenin]

вообще-то я об этом и написал... перечитайте плиз еще раз

ок, перечитал. вы практически цитируете мое первое и второе вообще сообщение в этой ветке. Как мы видим, это не аргументация для теоретиков.

[Vodazar]

Спасибо за ваши ответы по теме "advanced или basic". Я уже всё понял и определился по этому поводу.
Теперь помогите, пожалуйста, по проблеме, описанной в этом сообщении.

Кратко:
У меня 8 разных кабинетов для 8 групп(ролей) пользователей.
Некоторые пользователи могут иметь несколько ролей одновременно — member, admin, operator).
Есть несколько моделей, например User (профиль пользователя), Card (анкета или несколько анкет, привязанных к пользователю ), Bill (счёт(а)) и прочие, подобные.

К каждой из этих моделей у разных ролей есть доступ для редактирования, но доступен разный набор параметров для редактирования, например:
а. пользователь может редактировать только свой профиль, свой счёт, свою анкету (при этом он ещё не может менять в профиле свой логин и роль, в анкете не может ставить флаг проверки, а в счёте не может ставить флаг оплаты);
б. оператор может редактировать только профили и счета пользователей, которые к нему привязаны. При том имеет право выставлять флаг оплаты в счёте, меня логин пользователя, но не может например менять роль пользователя;
в. есть администратор, который может менять вообще всё что ему вздумается;
г. есть роль, которая позволяет привязывать пользователей к определённым операторам.

Как организовать структуру для максимально оптимального использования кода, без дублирования, с лёгкой поддержкой и адекватно настраиваемыми и редактируемыми параметрами доступа?

[zelenin]

Итак, отказался от advanced шаблона приложения. Решил использовать Basic.

Но проблема осталась. Прошу помочь выбрать правильное направление решения задачи:
1. У нас есть модель User с полями: name, password, email, state, role
2. У нас есть кабинет пользователя /cabinet/ в котором пользователь может изменить данные своего профиля: name, password
3. У нас есть кабинет модератора, /moderator/ в котором модератор может изменить данные любого пользователя: name, password, email, state
4. У нас есть кабинет админитстратора, /admin/ в котором администратор может изменить любые данные любого пользователя.
5. Есть ещё 5 подобных кабинетов.

Решения:
1. Использовать модули 1 модуль = 1 кабинет, в модуле указываем доступ только для одной роли.
Проблема в том, что нам тогда нужно дублировать контроллеры для редактирования профиля пользователя. А также создавать представление формы для каждого из кабинетов.
modules/cabinet/profile/index
modules/moderator/users/update/123
modules/admin/users/update/123

2. Использовать модули 1 модуль = 1 сущность
Получаем единственный модуль, который можно заменить на другой модуль или отказаться от его использования отключив в одном месте.
modules/users/profile/update
Встаёт проблема с разделением прав. Пользователи могут редактировать одно, модераторы другое, админы третье.
Получается надо делать разные экшены в одном контролере по количеству ролей?
modules/users/default/adminUpdate/123
modules/users/default/moderatorUpdate/123
Или через разные роуты
modules/users/cabinet/update
modules/users/admin/update/123
modules/users/moderator/update/123
Но тогда тоже неудобно, экшены или контроллеры жёстко связаны с системой ролей. При этом не понятно, нужно ли импользовать разные модели? Или сценарии в модели? А представления для формы? А как объединить потом разрозненные модули в один кабинет?

3. В предыдущей схеме с модулями можно ещё настроить доступ через RBAC, но тогда получается надо делать rule на каждую роль для update? А как изменять набор изменяемых полей в зависимости от текущей роли пользователя?

Заранее спасибо, кто прочитал эту портянку двойное спасибо, если ответите!

- делаете модуль, в котором будет BaseController, от него наследуете все остальное
- делаете standalone actions, чтобы не дублировать логику

ну и некоторые варианты, являющиеся модификациями этих двух

[Vodazar]

- делаете standalone actions, чтобы не дублировать логику

Вот! Это уже полезная подсказка куда можно копать, чтобы убрать дублирование, спасибо.

Про модуль и BaseController не совсем понял, модуль чего? Контроллер зачем?