Как лучше всего структурировать CakePHP Models

Question

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

Answer 1

Функциональность взаимодействия с БД должна быть размещена в моделях.например, сохранение данных, сохранение относительных данных, проверка, абстракция отношений между моделями ...

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

Вся функциональность, которая не связана напрямую с данной моделью или может использоваться во многих моделях, должна храниться в поведении.

Контроллеры должны быть очень легкими и легко читаемыми.они должны контролировать бизнес-процесс, используя функциональность модели, а также свою собственную.

И помните, что ваши модели должны быть толстыми, а контроллеры - худыми;).

PS

кулинарная книга для торта хорошо для начала.

Answer 2

Здесь вы можете найти руководство по эксплуатации моделей . Если вам нужны более конкретные ответы о том, как API работает с моделями, вы можете попробовать официальную страницу API . Кроме того, я погуглил и нашел повторяющиеся статьи об этой паре Fat Model и Skinny Controller практика , которые вы могли бы найти полезными.

Как общий ответ, Модели:

Модели представляют данные и используются в Приложения CakePHP для доступа к данным.

По сути, с помощью моделей вы управляете данными базы данных и отображаете их в контроллере (рассматривая контроллер также как связующее звено между View, Controller и Models). Следующие слова лучше всего описывают практическое использование модели:

Модель обычно представляет собой базу данных таблица

Таким образом, если у вас есть таблица user, вы должны создать хотя бы одну модель для управления всем, что вы хотите контролировать в таблице user базы данных. Например, вы можете получить к нему доступ с помощью User::create($name, $password, $email) или User::edit($id, $set, $value) и изменить таблицы, связанные с базой данных user.

Answer 3

Модель - это ссылка на определенный набор данных.Это может быть база данных, текстовый файл или любой другой тип данных.Необходимо помнить, что одна модель должна ссылаться на один набор данных.Для простоты приведу таблицу пользователей.Предположим, у нас есть следующая таблица в базе данных:

CREATE TABLE `users` (
  `id` char(36) NOT NULL,
  `email_address` varchar(127) NOT NULL,
  `password` varchar(40) NOT NULL,
  PRIMARY KEY (`id`)
);

Базовая модель для этой таблицы будет выглядеть примерно так:

<?php
class User extends AppModel {
    var $name = 'User';
    var $displayField = 'email_address';
}

Теперь ключ к архитектуре MVC (и CakePHP) заключается в том, что любая функция, необходимая для манипулирования данными пользователя, должна содержаться в этой модели.Это немного широкий и широкий.Могут быть случаи, когда это будет происходить в другом месте.Но если вы всегда можете думать о вещах с точки зрения данных или бизнес-требований / процессов, это поможет вам определить, куда должен идти код.

Так что для модели пользователей, если вам нужно ДОБАВИТЬ пользователя,модель справится с этим дополнением.Контроллер вызывает форму (представление), а затем обрабатывает форму, отправляя данные в модель для добавления в базу данных.

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

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

Надеюсь, это поможет.

Answer 4

Абстрактный вид:

Может быть трудно применить это полностью в Cake, но экземпляр модели (в смысле MVC) представляет собой объект, а не таблицу базы данных или просто слой доступа к данным.

Например, экземпляр модели User представляет конкретного пользователя.

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

/**
 * Send an SMS to user
 *
 * @precondition $this->data has been set
 * @param string $msg
 * @return void
 */
public function sendSms($msg) {
    $this->smsGateway->send($this->data['User']['mobile'], $msg);
}

Предварительное условие указывает, что User->read() должен быть вызван до того, как этот метод будет работать правильно. Вы можете подумать, что это немного анально для слабо типизированного языка, но преимущество в том, что ваши модели начинают больше походить на реальный мир, который они моделируют, и, делая предположения и придерживаясь их, вы можете упростить ваш код === win.