ORM в цмс magento

Прочитав данный пост habrahabr.ru/post/303028/#first_unread. Я призадумался а почему многие разработчики не спешат её использовать? И почему у людей складываеться мнение, что они умнее тех кто разрабатывал, и поддерживал этот функционал годами. И как вы уже догадались поговорим о ORM!

Дело в том что, 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. Хоть бы кто нибудь отписался почему минусует…