Self-made ORM for Bitrix

Despite the fact that the Bitrix developers announced the module with ORM support at the end of last year, and the fact that this module was declared in the list of available in almost all editions, it really isn’t included yet, as there is no documentation on it. We will leave behind the scenes the unethical inclusion of missing features in the product description in the purchase section, back to ORM. Since it is not there, why not implement something similar on your own?





For the impatient, I’ll immediately give a link to the source code of the module, on GitHub. It’s kind of a prototype - because it has some problems, and not all moments are solved beautifully, but nevertheless, it already works. So still our product. Although a prototype. It took less than 4 hours to write the code, with all that it implies.

Usefulness

• Implemented a mechanism for creating objects of the desired classes through the factory.
  

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

  
  
• There is support for setters and getters that are automatically applied when working with fields.
  

  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;
      }
  }
  

  
  
• All basic actions have been implemented (create, delete, modify, search by various filters).
  

  $ormNews = ORM::Factory(4);
  $list=$ormNews->Where("WIDTH","=","140")->FindAll();
  foreach ($list as $_news){
      $_news->NAME="Новость с номером {$_news->ID}";
      $_news->WIDTH=24;
      echo "
  ".print_r($_news->AsArray(true),true)."
  ";
      if ($_news->ID%2==0) $_news->Delete(); else {
          $_news->NAME.=" [обновлена!]";
          $_news->Save();
      }
  }
  

  
  
• Work with both standard fields and custom properties is exactly the same.
• There is a peculiarity when working with fields of the "list" type. For example, we have a property COLOR. When working with it, two fields will be visible - COLORcontaining the text value of the selected list item, and COLOR__ID(two underscores) containing the ID of the selected option. To change the value, you need to assign it the ID of another variant of the list (for example $item->ID=5), while automatically COLOR__IDreceiving this value, and COLOR- will change the text value.

disadvantages

• some decrease in speed. It works with an existing API for working with information block data, and not directly with the database. On the other hand, these parts can also be rewritten, after which all the code associated with this ORM will continue to work
• works exclusively with items (not folders)
• there are no normal mechanisms for complex queries with nested queries, with OR queries.
• there is no possibility to fill array properties (multiple properties) with a query of the form $ obj-> item [] = "value"; Instead, you have to use AddToArrayValue ("item", "value") for now. How to get around this point, has not yet figured out.
• there is no solution for creating dependencies between infoblocks (one to one, one to many, etc.)