Класс Phalcon\Mvc\Model Phalcon предназначен для обеспечения объектно-ориентированного способа взаимодействия с базой данных. Например, если ваша таблица Shopping_Cart, то вы можете назвать свой класс ShoppingCart. Если в вашей таблице есть столбец «id», вы должны определить свойство в своем классе public $id;.
Phalcon также предоставляет вам методы, подобные initialize() и beforeValidationOnCreate(). Я соглашусь, что эти методы могут быть очень запутанными в отношении того, как они работают, и когда они бегают, и почему вы когда-либо хотели бы назвать это в первую очередь.
initialize() вполне понятен и вызывается при каждом запуске вашего класса. Здесь вы можете делать такие вещи, как setSource, если ваша таблица названа иначе, чем ваш класс, или методы вызова, такие как belongsTo и hasMany, чтобы определить ее связь с другими таблицами.
Взаимодействие полезно, так как позволяет легко сделать что-то вроде поиска продукта в корзине пользователя, а затем используя идентификатор, вы получите ссылку на таблицу Accounts и, наконец, возьмите имя пользователя продавца в корзине покупателя.
Я имею в виду, конечно, вы могли бы делать отдельные запросы для такого рода материалов, но если вы определяете отношения между таблицами в самом начале, почему бы и нет?
С точки зрения определения выделенной модели для каждой таблицы в базе данных вы можете определить свои собственные методы управления моделью. Например, вы можете определить метод public function updateItemsInCart($productId,$quantity) в своем классе ShoppingCart. Тогда идея заключается в том, когда вам нужно взаимодействовать с ShoppingCart, вы просто вызываете этот метод и позволяете модели беспокоиться о бизнес-логике. Это вместо написания сложного запроса update, который также будет работать.
Да, вы можете положить этот материал в свой контроллер. Но есть также принцип СУХОЙ (не повторяй сам). Целью MVC является разделение проблем. Итак, зачем следовать MVC в первую очередь, если вы не хотите раздел посвященных моделей? Ну, возможно, вам это не нужно. Не для каждого приложения требуется модель. Например, этот код не использует: https://github.com/phalcon/blog
Лично, после использования структуры модели Phalcon некоторое время я начал нелюбоваться их одноуровневым подходом к Модели. Я предпочитаю многоуровневые модели больше в отношении объектов, сервисов и репозиториев. Вы можете найти такой код здесь: https://github.com/phalcon/mvc/tree/master/multiple-service-layer-model/apps/models Но такое может стать чрезмерным, очень быстро и трудно справиться из-за чрезмерной абстракции. Решение где-то между ними обычно возможно.
Но, честно говоря, нет ничего плохого в использовании встроенного адаптера базы данных Phalcon для ваших запросов. Если вы столкнулись с очень сложным запросом, никто не сказал, что каждая из ваших моделей должна расширить Phalcon\Mvc\Model. Это по-прежнему совершенно здравая логика, чтобы написать что-то вроде:
$pdo = \Phalcon\DI::getDefault()->getDb()->prepare($sql);
foreach($params as $key => &$val)
{
$pdo->bindParam($key,$val);
}
$pdo->setFetchMode(PDO::FETCH_OBJ);
$pdo->execute();
$results=$pdo->fetchAll();
модель является очень гибкой, нет «лучшего» способа организовать их. Подход «все работает» прекрасен. Как и «Я хочу, чтобы мои модели имели метод для каждой операции, которую я мог бы когда-либо хотеть».
Допустим, что полуфункциональные примеры и (построенные только для демонстрационных целей) не так хороши для восприятия хороших моделей проектирования. Я бы посоветовал найти часть программного обеспечения, которое действительно используется в серьезной манере, например код для форумов: https://github.com/phalcon/forum/tree/master/app/models
Phalcon по-прежнему довольно новшеств в структуре, чтобы найти хорошие модели для подражания.
Как вы упомянули, в отношении наличия всех моделей в одном файле это прекрасно. Обратите внимание, как упоминалось ранее, используя setSource в пределах initialize, вы можете назвать свои классы иначе, чем таблица, над которой они работают. Вы также можете использовать пространства имен и сопоставлять классы с именами таблиц. Вы можете сделать это еще дальше и создать один класс для динамического создания всех ваших таблиц с помощью setSource. Предполагается, что вы хотите использовать адаптер базы данных Phalcon. Нет ничего плохого в написании собственного кода поверх PDO или другого адаптера базы данных.
Как вы говорите, разделение проблем не так важно для вас в небольшой команде, поэтому вы можете уйти без каталога моделей. Если это какая-то помощь, вы можете использовать что-то вроде того, что я написал для вашего адаптера базы данных: http://pastie.org/10631358
, тогда вы бросили это в свой каталог приложений/библиотек.Загрузите компонент в вашей конфигурации, как так:
$di->set('easySQL', function(){
return new EasySQL();
});
Затем в Basemodel вы бы поставил:
public function easyQuery($sql,$params=array())
{
return $this->di->getEasySQL()->prepare($sql,$params)->execute()->fetchAll();
}
Наконец, от модели, вы можете сделать что-то просто:
$this->easyQuery($sqlString,array(':id'=>$id));
Или определить функцию в глобальном масштабе, так что ваши контроллеры могут также использовать его и т.д.
Есть и другие способы сделать это. Надеюсь, мой компонент «EasySQL» приблизит вас к вашей цели. В зависимости от ваших потребностей, может быть, мой компонент «EasySQL» просто длинный путь написания:
$query = new \Phalcon\Mvc\Model\Query($sql, $di);
$matches=$query->execute($params);
Если нет, то, возможно, вы ищете что-то более в направлении
$matches=MyModel::query()->where(...)->orderBy(...)->limit(...)->execute();
Который является прекрасно.
Если все, что вы разрабатываете, представляет собой базовую систему CRUD с одной моделью на один контроллер, тогда вам не нужно это разделение ... но для бизнес-систем каждый контроллер может получать доступ к данным из нескольких разных моделей , и модель может ссылаться на несколько разных контроллеров ..... и тогда разделение важно. –
Контроллер является посредником между вашими моделями и клиентом. Вы разделяете контроллеры с уровня модели, потому что могут быть разные способы запросить одни и те же модели: например, HTTP API, CLI, Some-other-crazy-api. Во всех этих трех случаях вы взаимодействуете с одними и теми же моделями, но с помощью разных API. Что означает - чем меньше знаний API о вашей модели, тем лучше. – zerkms