Дело в том что, magento построена на патерне MVC, и это не для кого не секрет. Расмотрим модель, ибо модель и есть частная реализация Entity manager. Допустим у нас есть таблица `«mymodule_mytable»`, и соответственная модель `«mymodule/mytable»`.
Получаем модель:
$myModule = Mage::getModel('mymodule/mytable')
При инициализации модели. Magento автоматом создаёт сетеры и гетеры, точнее они реализованны с использованием магических методов `__set()` и `__get()`. К примеру наше сущьность(таблица в базе данных) имеет поля `id,first_name,last_name`
Далее расмотрим, повседневные операции над таблицами:
1. Создание строки `insert` в mysql, на объектным диалекте магенты это будет выглядеть так
try {
$myModule
->setFirstName('myFirstName')
->setLastName('myLastName')
->save();
} catch(Exception $error) {
// error loging
}
2. Выборка строки из базы, поля по `id`:
$myModule->load($id);
3. Изменения строки
try {
$myModule
->load($id)
->setFirstName('MyFirst')
->save();
} catch(Exception $error) {
//loging error
}
4. Транзакции
// ...
$adapter = $this->_getWriteAdapter();
// ...
$adapter->beginTransaction()
try {
$myModel->setFirstName('MyFirstName')->save();
$adapter->commit();
} catch(Exception $error) {
$adapter->rollback();
}
Это базовые свойства модели, Наверное вы спросите, а как же получить некое количество данных, используя ORM? Дело в том что в магенто есть реализация collection. Создаёться отдельный фаил для подгрузки коллекции. Тут я должен, сделать небольшое отступление, если ваша модель работает с базой данных, то она точно будет иметь реализацию resource, и collection. Я понимаю что это надо было написать ещё в начале. Но я не стал этого делать. Так как мы говорим о ORM.
Продолжим рассматривать операции на ORM над таблицами:
5. Выборка всех полей из таблицы:
$myCollection = $myModel->getCollection()->load();
6. Фильтрация полей
$myCollection = $myModel->getCollection();
$myCollection->addFieldToFilter('first_name',array(
'eq' => 'MyFirstName'
));
$myEntityes = $myCollection->load();
Не буду рассматривать все доступные методы они похожи на mysql `like,in,notlike,regexp,notin` и д.р. всё это есть в документации.
7. Выборка определёных полей
$myCollection->addFieldToSelect(
array('id','first_name');
)
А где же join скажете вы? С join более сложнее так как в большинстве случаев мы должны создать EAV model, Entity-attribute-value (сущность атрибуты значения). Для большинства задач мы должны создать EAV модель, в которой будут храниться некие атрибуты нашей сущности. join в коде это некий кастыль, так как в какой то момент разработки у нас есть `id|first_name|last_name` и после неких доработок мы приходим к `id|first_name|last_name|data1|data2… data322`, и тут разработчик вдруг решает, сделать ещё таблицу которую будет joinit для модификации и записи, каких либо дополнительных полей. В конце концов мы приходим к тому что не можем просто решить элементарные задачи не изменив таблицы, не поправив `join` и запросы…
Как рас EAV решает эту проблему вы можете с лёгкостью добавить аттрибут и работать с ним, вы можете дать возможность пользователю добавлять новые аттрибуты, и небояться что у вас что то где то отвалиться или измениться…
И на этом я закончу, если статья будет интересна я напишу продолжение о создание eav model, и использование таких моделей…
P.S. Хоть бы кто нибудь отписался почему минусует…
Комментарии (27)
AlexLeonov
02.07.2016 23:05+5Ну и за использование array() пожалуй можно смело попросить автора этого кода «вон из профессии».
andrewnester
03.07.2016 21:20ну я бы не был так категоричен, у нас на некоторых версиях проекта ещё заявлена поддержка 5.3 и без array() там никак к сожалению
AlexLeonov
03.07.2016 23:36+1Перестаньте заявлять такую поддержку. Она не нужна. Никому.
andrewnester
04.07.2016 12:16я же ведь сказал — на некоторых версиях — на других версиях мы уже отказались.
lnroma
03.07.2016 21:44-1Вы наверное из тех кто считает можно наплевать на PSR-1 и PSR-2, magento на ZF1 и оформление кода там по https://framework.zend.com/manual/1.12/ru/coding-standard.coding-style.html этому кодинг гайду. Ну а если вы из тех людей которые забивают на coding style, и на php-doc и другие не интересные штуки. То вон из профессии вас и всех тех кто так программирует.
Delphinum
02.07.2016 23:08+7А разве добрая PDO и PDOStatement не умеет то же самое? Или соль тут в Query Builder?
Не увидел ORM. В чем цель статьи?
AlexLeonov
02.07.2016 23:09+8А минусуют Вас потому, что это не статья уровня Хабра, а некий текст, напоминающий худшие образцы «Ответов.Mail.Ru». Как по бессмысленности содержания, так, особенно, по безграмотности.
bull1251
10.11.2016 23:54Я поэтому указал в тексте:
> мы изначально должны были видеть на экране смесь интерференций и двух полос. А значит, мы изначально не могли бы определиться с противоположным выбором, что снова приводит нас к парадоксу…
Если мы не можем определиться с выбором, то у нас возникнет время подумать — продолжать или не продолжать эксперимент. Причем вероятность второго на мой взгляд превышает первое. Если мы всё же решим продолжить, то возникает выбор — наблюдать или не наблюдать за фотоном, что еще больше увеличивает вероятность второго.
Т.е. вероятность двух событий не равно между собой, а это создает возможность противоположного выбора. Возможность противоположного выбора пытается усреднить картину, что снова приводит нас вышеуказанному изменению вероятности с нашей стороны. Так что же должно отображаться на экране? Парадокс.
michael_vostrikov
03.07.2016 08:17+8Хоть бы кто нибудь отписался почему минусует
Ок, напишу.
Получаем модель
При инициализации модели.
Изменения строки
Транзакции
У вас в статье наверное штук 40 предложений, и четверть из них вот такие односложные заголовки. А также куча орфографических и пунктуационных ошибок. Это не статья, а огрызок. Вам сильно понравится, если кто-то предложит вам огрызок?
Вы бы хоть в Ворде орфографию проверили, раз сами не знаете.
всё это есть в документации
А зачем тогда нужна ваша статья? Про ORM тоже есть в документации. Кстати, вы бы хоть ссылку на нее оставили.
А где же join скажете вы? С join более сложнее
JOIN между таблицами — это связи между объектами, то есть буква R в ORM. Статья вроде как про ORM, а такой важной части нет.
«Я потом напишу, если попросите». Что за манера такая?
Ulitkus
03.07.2016 17:41К сожалению про связи между сущностями разработчики Magento почему-то забыли. По крайней мере, в первой версии, про вторую не знаю
M-A-XG
03.07.2016 17:55-1Да?
Олени.
Зато энтерпрайс, и на фреймворке, можно корчить из себя крутого перца. :)Ulitkus
03.07.2016 18:00Да, и это боль ) Возможно, это оттого, что архитектура Magento 1 была разработана довольно давно (2008 — 2009), тогда ещё не знали как надо.
maxru
04.07.2016 13:16А до этого они не знали, как надо, написав osCommerce, ага :)
Ulitkus
04.07.2016 13:37Не знал, что они и там засветились. Справедливости ради, кто-нибудь может привести пример популярной e-commerce платформы, с которой было бы удобно работать с точки зрения программиста? Язык значения не имеет
oxidmod
04.07.2016 14:17OXID eShop весьма весьма. не так академична как magento, но большинство задач решаются довольно легко
maxru
04.07.2016 17:43Ни одной не смогу вспомнить. UMI был хорош как пример сферического ООП ради ООП в вакууме и только.
XoJIoD
11.11.2016 12:40Это ясно, спасибо. Но суть описанного эксперимента заключается в том, что мы откладываем решение о том, куда направить холостые фотоны. Т.е. уже после попадания сигнальных на экран мы решаем, направить ли холостые на детектор А (который даст нам однозначную информацию о пути), либо на детектор Б (или вообще вникуда). Что будет в этом случае?
AlexLeonov
Создать объект-модель для того, чтобы получить из БД объект-модель? Совершенно идиотский подход, пахнущий PHP 5.2 и Yii 1.
Код читать надо. Вслух. Тогда вам будут сразу видны все его огрехи.
lnroma
Во первых статья для разработчиков magento. А во вторых: `Создать объект-модель для того, чтобы получить из БД объект-модель?` вопрос странновато из БД вы получите только данные, если это только не mongoDB речь идёт о mysql, даные в объект может преобразовать PDO или mysqli(на счёт последнего незнаю что он возвращает). В третих ORM это прослойка абстракции т.е. Если смотреть на прототип, мы увидим следующую последовательность. `db->driver->entity manager->model` очень упрощённо откидывая query builder и то что этот объект находиться в registry и имеет один инстанс во время работы приложения. Если приложение ориентированно на mysql или любую другую бд то в orm смысла нет. А для реализации, архитектуры которая не зависит от места хранения данных, необходима реализация как рас какой то прослойки между базой-данных и моделью приложения(проще говоря той штуки с которой он будет работать). И только тогда для миграции приложения на postgresql (к примеру) вам надо будет написать лиш driver. В другом же случае, вам придёться переписывать всё приложение полностью.
EvgK
Объяснение было совершенно верным. Обычно в таких экспериментах (а их версий существует множество), «сигнальные» фотоны не образуют никакой картины и их расположение хаотично, и таким оно и остается до тех пор, пока мы не узнаем судьбу «холостых» фотонов. Дальше мы выбираем из этой хаотической картины сигнальные фотоны, соответствующие некоторым «холостым» (например, холостых зафиксированных одним из детекторов в нашей схеме) и видим, что действительно, эти соответствующие фотоны образуют интерфереционную картину (или наоборот — не образуют, в зависимости от деталей эксперимента). Поскольку до получения информации о состоянии холостых фотонов (обычным путем, не выше скорости света) мы видим только случайное распределение сигнальных — получить таким образом информацию «из будущего» (или «выше скорости света», что по сути одно и то же) мы не можем.