Самопальная ORM для Битрикс

в 4:12, , рубрики: 1С-Битрикс, orm, php, битрикс, метки: , ,

Не смотря на то, что модуль с поддержкой ORM разработчики битрикса анонсировали ещё в конце прошлого года, и того, что этот модуль заявлен в списке доступных в практически всех редакциях, реально его пока что нет в комплекте, как нет по нему и документации. Оставим за кадром неэтичность включения отсутствующих фич в описание продукта в разделе покупки, вернемся к ORM. Раз его нет — почему бы не реализовать нечто подобное самостоятельно?

Самопальная ORM для Битрикс
Самопальная ORM для Битрикс

Для нетерпеливых — сразу дам ссылку на исходники модуля, на GitHub'е. Это как-бы прототип — потому что имеет некоторые проблемы, да и не все моменты решены красиво, но тем не менее, он уже работает. Так что всё-таки наш продукт. Хоть и прототип. На написание кода ушло менее 4х часов, со всеми вытекающими.

Полезности

  • Реализован механизм создания объектов нужных классов через фабрику.
    $item=new ORM(5); //создаем объект инфоблока с номером 5
    $item=ORM::Factory(5); //аналогично
    
    $item=new ORM("news"); //создаем объект инфоблока с CODE=news
    
    $item=ORM::Factory("news"); //сначала будет попытка создать объект класса newsBitrixOrm или NewsBitrixOrm, если таковой не будет найдет - попытка создать объект инфоблока с CODE=news
    

  • Есть поддержка сеттеров и геттеров, автоматически применяемых при работе с полями.
    class NewsBitrixORM extends ORM{
        protected $IBlockID=1;
        protected $auto_getters = array("NAME"=>"GetNameValue");
        protected $auto_setters = array("NAME"=>"SetNameValue");
        
        public function GetNameValue($value){
            return str_replace(" (имя новости!)", "", $this->_data["NAME"]);
        }
        public function SetNameValue($value){
            $this->_data["NAME"]=$value." (имя новости!)";
            $this->_changed_fields["NAME"]="NAME";
            return true;
        }
    }
    

  • Реализованы все базовые действия (создание, удаление, изменение, поиск по различным фильтрам).
    $ormNews = ORM::Factory(4);
    $list=$ormNews->Where("WIDTH","=","140")->FindAll();
    foreach ($list as $_news){
        $_news->NAME="Новость с номером {$_news->ID}";
        $_news->WIDTH=24;
        echo "<pre>".print_r($_news->AsArray(true),true)."</pre>";
        if ($_news->ID%2==0) $_news->Delete(); else {
            $_news->NAME.=" [обновлена!]";
            $_news->Save();
        }
    }
    

  • Работа как со стандартными полями, так и с пользовательскими свойствами идет совершенно одинаково.
  • Есть своя особенность при работе с полями типа «список». Например, у нас есть свойство COLOR. При работе с ним будет видно два поля — COLOR, содержащее текстовое значение выбранного элемента списка, и COLOR__ID (два подчеркивания), содержащее ID выбранного варианта. Для изменения значения нужно назначить ему ID другого варианта списка (например $item->ID=5), при этом автоматически COLOR__ID получит это значение, а COLOR — изменит текстовое значение.

Недостатки

  • некоторое уменьшение скорости. Работает с уже существующим API для работы с данными инфоблоков, а не напрямую с базой. С другой стороны, эти части можно и переписать, после чего весь код, завязанный на данную ORM продолжит работать
  • работает исключительно с элементами (не с папками)
  • отсутствуют нормальные механизмы для сложных запросов со вложениями запросами, с OR-запросами.
  • отсутствует возможность наполнять свойства-массивы (множественные свойства) запросом вида $obj->item[]=«значение»; Вместо него пока приходится использовать AddToArrayValue(«item»,«значение»). Как обойти этот момент, пока что не придумал.
  • отсутствует решения для создания зависимостей между инфоблоками (один к одному, один ко многим и т.п.)

Автор: Newbilius

Источник

Поделиться

* - обязательные к заполнению поля