Лучшие практики Контроллера
В хорошо разработанных приложениях контроллер лаконичен и содержит короткий рабочий код; если ваш контроллер сложный, это обычно означает, что вам необходимо выполнить рефакторинг и перенести некоторый код в другие классы.
Ответственность контролера
1. Доступные данные запроса
// GET parameter $get = Yii::$app->getRequest()->get(); $get = Yii::$app->getRequest()->getQueryParams(); // POST parameters $post = Yii::$app->getRequest()->post(); $post = Yii::$app->getRequest()->getBodyParams();
2. Метод и другие сервисные компоненты модели могут быть вызваны на основе данных запроса
$searchModel = new ArticleSearch();
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);
$websiteKv = Website::kv('id', 'title');
$model = $this->findModel($id);
$model->load(Yii::$app->request->post());
$model->save()3. Используйте представления для построения ответов
return $this->render('edit', [
'model' => $model,
'subjectKv' => $subjectKv
]);4. Данные запроса, которые должны быть обработаны моделью, не должны обрабатываться
Например, отправьте форму Y-m-d Формат времени преобразуется в метку времени и так далее, которая обрабатывается в модели.
5. Избегайте встраивания HTML или другого кода презентации, который лучше всего обрабатывается в представлениях
Пример Наилучшей Практики
Модель-это центральное место, представляющее бизнес-данные, правила и логику. Он часто используется повторно во многих местах. В хорошо разработанном приложении модель обычно представляет собой нечто большее, чем код контроллера.
Типовая ответственность
1. Атрибуты могут быть включены для отображения бизнес-данных
Он в основном сопоставляет поля таблицы данных с атрибутами в классе модели и может соответствующим образом добавлять пользовательские общедоступные атрибуты.
2. Правила проверки могут быть включены для обеспечения достоверности и полноты данных
Метод правил () и т. Д.
3. Может включать методы реализации бизнес-логики
public function getSubject()
{
return $this->hasOne(Subject::className(), ['sid' => 'sid']);
}
public function getMedia()
{
return $this->hasMany(ArticleMedia::className(), ['aid' => 'aid']);
}
public function updateStatus($status)
{
return $this->updateAttributes(['status' => $status]);
}4. Запросы, сеансы и другие данные об окружающей среде не должны быть доступны напрямую, а должны передаваться от контроллера к модели.
Не используйте Yii::$app->GetRequest() Следующий метод может использоваться только в контроллере.
5. Избегайте встраивания HTML или другого кода презентации, который лучше всего обрабатывается в представлениях
6. Избегайте слишком большого количества сценариев в одной модели
Это предложение всегда следует учитывать при разработке больших и сложных систем, в которых модели велики и используются во многих местах и, следовательно, содержат наборы правил и бизнес-логику. Наконец, поддержание кода модели становится кошмаром, потому что простая модификация может повлиять на многие места. Для обеспечения надлежащего функционирования модели лучше всего использовать следующие стратегии.
- Определите набор базовых классов модели, которые могут совместно использоваться несколькими агентами приложений или модулями. Эти классы моделей должны содержать общий минимальный набор правил и логики.
- В каждом предмете или модуле приложения, использующем модель, конкретный класс модели определяется путем наследования соответствующего базового класса модели, который содержит правила и логику, заданные предметом или модулем приложения.
Например, в расширенных шаблонах приложений вы можете определить базовый класс модели common\models\Post Затем в приложении переднего плана определить и использовать наследование common\models\Post Конкретные классы моделей интерфейс\модели\Post Он может быть аналогичным образом определен в фоновых приложениях backend\models\Post . Благодаря этой стратегии вы знаете, что frontend\models\Post Только для интерфейсного приложения, если вы его измените, нет необходимости беспокоиться о том, что изменение повлияет на серверное приложение.
Просмотр Лучших Практик
Представления отвечают за отображение данных модели в нужном пользователям формате
Посмотреть ответственность
1. Он должен в основном включать код отображения, такой как HTML, и простой PHP-код для управления, форматирования и визуализации данных.
2. Код запроса данных выполнения не должен включаться в модель
Когда вы почувствуете, что вам нужно использовать запрос базы данных в GridView, сначала подумайте, может ли функция joinWith () заменить запрос. Если да, то используются таблицы объединения; если нет, то запросы к данным можно использовать соответствующим образом.
3. Избегайте прямого доступа к данным запроса, таким как$_GET, $_POST. Это должно быть выполнено в контроллере и передано контроллером в представление, если необходимо запросить данные
4. Свойства модели можно прочитать, но их не следует изменять
5. Чтобы упростить обслуживание модели и избежать создания представлений, которые являются слишком сложными или содержат слишком много избыточного кода, для достижения этой цели можно использовать следующие подходы:
- Используйте макет для отображения общего кода (например, заголовок и конец страницы);
- Сложные виды разделены на несколько небольших видов, которые могут быть отрисованы и собраны в большие виды с использованием метода отрисовки, описанного выше.
- Создавайте и используйте виджеты в качестве блоков данных для представлений;
- Создавайте и используйте вспомогательные классы для преобразования и форматирования данных в представлениях.
Уровень обслуживания (Уровень Бизнес-Логики)
Структура MVC состоит из модели, представления и контроллера. Процесс выполнения, как правило, таков: модель доступа в контроллере для получения данных и отображения страниц через представление.
Модель MVC является базовым режимом в веб-разработке. Он использует многоуровневый дизайн и имеет четкие обязанности между слоями. Однако, вопреки нашим пожеланиям, когда мы со временем разработаем модель на основе MVC, мы постепенно почувствуем сцепление и неоднозначность между слоями, что является важной причиной появления Сервисного слоя.
Платформа Yii2 рекомендует размещать большую часть бизнес-логики в классах моделей. Когда бизнес-логика относительно проста, она может сделать структуру кода понятной и увеличить частоту повторного использования кода. Однако при разработке больших сложных систем бизнес-логика будет более сложной, объем кода классов моделей будет очень большим, обычно включающим несколько классов моделей, что увеличивает связь между классами моделей, что не способствует обслуживанию.
Служебные обязанности
1. Разделение классов моделей
Сложная бизнес-логика, требующая участия нескольких моделей, инкапсулируется отдельно. Эти модели больше не полагаются непосредственно друг на друга, а взаимодействуют для завершения логики на уровне обслуживания.
2. Упростите бизнес-логику классов моделей
Класс модели должен иметь дело только с простой бизнес-логикой. Когда бизнес-логика метода более сложна (например, некоторые статические методы статистических функций), рекомендуется, чтобы бизнес-логика обрабатывалась на уровне обслуживания.