Сайт-визитка на Laravel. Этап 7 – модели для работы с таблицами

В прошлой статье я мельком коснулся создание класса модели. Теперь перейдем к более практической части.В нашем простом примере эта часть тоже больше теоретическая.

Модель нужна в парадигме MVC для получения/изменения данных. Они могут находиться в массивах, таблицах базы или в файлах, что совершенно не важно. Laravel, как почти каждый фреймворк на php,  предлагает механизм работы именно с базами данных MySQL, PostgressSLQ, SQLite 3. Наиболее часто используют первый и последний вариант. Мы уже настраивали фреймворк на работу с MySQL. Так что и будем с ней продолжать работать.

Идеология разработки в Laravel предполагает, что в моделях делается только получение и изменение в данных. Все проверки и бизнес-логика находится в контроллерах. Впрочем, вы можете часть проверок вынести и в модели – тут полная свобода действий.

Класс Eloquent

Модели в Laravel наследуются от класса Eloquent, который вынесен в отдельный пакет, устанавливаемый по умолчанию. При желании, в другой фреймворк можно его подключить так же (я встречал статьи о подключении его к микрофреймворкам Slim, Silex и к новому фреймоворку Lumen).

Класс Eloquent имеет уже готовые методы для работы с данными: получить, изменить, удалить и так далее. Так же в нем можно задать отношения между таблицами «один-к многим» и «многие – ко многим». Ну и для полного контроля над sql-запросами есть свой SQL-Builder, повторяющий во многом язык запросов sql.

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

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

/* Примеры обращение к модели: */
$posts = Post::all();   // Получить все записи в массив
$user = User::find(1);  // Получить запись по первичному ключу id
$model = User::where('votes', '>', 100)->firstOrFail(); //Получить запись где поле votes больше 100,
//если не найдена генерируется исключение и можно вывести ошибку 404
$user->delete(); // Удаление записи
User::destroy(1); // Удаление записи в таблице по ключу

Интересно, но даже проверки, выборки данных в видеоуроках делают в контроллерах, что не совсем правильно с точки зрения концепции MVC.

Защита данных

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

Если вы не укажите явно доступные поля, то запись в таблицу не пройдет. И правильно – некоторые данные вы не должны трогать «руками», о них заботится сам Laravel. Это id записи, даты создания, даты изменения и так далее. Поэтому нужно прежде всего разрешить изменять записи:

    protected $fillable = ['title', 
                           'slug', 
                           'menu', 
                           'description', 
                           'keywords', 
                           'image', 
                           'staus', 
                           'body'
    ];

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

Можно проверку на разрешенные поля отключить, но не стоит это делать.

Есть массив protected $guarded, который обратный массиву $fillable — он наоборот запрещает писать в поля.

Проверка данных

Перед записью в таблицу данных от пользователя нужно их обязательно проверить. Для этого есть специальный класс валидации. В моделях обычно располагают массив, где описывают правильные значения каждого поля. Когда вы получаете от пользователя данные из формы, каждое поле сравнивается с правилами. Если все нормально, то происходит действие. Иначе будут выводиться ошибки валидации, которые можно обработать и показать пользователю.

Опять же, часто в видеоуроках этот массив пишут в контроллере и затем делают валидацию данных. По моему мнению, так не стоит делать, потому что вы можете обращаться к модели из нескольких контроллеров и вам придется дублировать массив.

Вот правила валидации для модели Post:

public static $rules = ['title' => 'required|between:3,255',
                        'slug' => 'required',
                        'description' => 'required|between:3,255',
                        'keywords' => 'required|between:3,255',
                        'image' => 'required',
                        'body' => 'required',
                        'status' => 'required'
];

По валидации будет отдельная статья, сейчас на ней не буду задерживаться подробно.

Заключение

Смешно, но в реальных проектах в моделях кроме этих двух массивов обычно почти ничего нет! Из-за удачного класса Eloquent все делается автоматом.

Сложности начинаются позже при сложной структуре базы данных и сложных правил обработки. Но мы пишем визитку и разбираем класс статических страниц (самый простой), а потому нам будет достаточно такой простой модели.

Ну а сам проект подходит к следующей интересной точке – контроллерам. Но это уже тема другой статьи ?