Self-made ORM for Bitrix

Despite the fact that the module with ORM support was announced by the Bitrix developers at the end of last year, and the fact that this module is included in the list of available in almost all editions, in reality it is not yet included, as there is no documentation on it. Let's 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 like this yourself?





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

Utility

• The mechanism for creating objects of the required classes through the factory has been implemented.
  

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

  
  
• Implemented all the basic actions (create, delete, modify, search on various filters).
  

   $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(); } } 

  
  
• Working with both standard fields and custom properties is exactly the same.
• It has its own peculiarity when working with “list” fields. For example, we have the COLOR property. When working with it, you will see two fields - COLOR , containing the text value of the selected list item, and COLOR__ID (two underscores), containing the ID of the selected option. To change a value, you need to assign it an ID of another variant of the list (for example, $item->ID=5 ), while COLOR__ID will automatically receive this value, and COLOR will change the text value.

disadvantages

• some decrease in speed. It works with the already existing API for working with information block blocks, and not directly with the database. On the other hand, these parts can be rewritten, after which all the code tied to this ORM will continue to work
• works exclusively with items (not with folders)
• there are no normal mechanisms for complex requests with attachments requests, with OR-requests.
• there is no possibility to fill arrays (multiple properties) with a query of the form $ obj-> item [] = “value”; Instead, you have to use AddToArrayValue ("item", "value"). How to get around this moment, has not yet been invented.
• there is no solution for creating dependencies between information blocks (one to one, one to many, etc.)