Bitrix用の自作ORM

Bitrix開発者が昨年の終わりに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
  
  
  
  と、選択したオプションのIDを含むCOLOR__ID
  
  
  
  （2つの下線）の2つのフィールドが表示されます。 値を変更するには、別のリストオプションのID（たとえば、 $item->ID=5
  
  
  
  ）を割り当てる必要がありますCOLOR__ID
  
  
  
  は自動的にこの値を受け取り、 COLOR
  
  
  
  はテキスト値を変更します。

短所

• 速度が多少低下します。 データベースではなく、情報ブロックデータを操作するための既存のAPIで機能します。 一方、これらの部分は書き換えることもできます。その後、このORMに関連付けられたすべてのコードは引き続き機能します
• （フォルダではなく）アイテムのみで動作します
• ネストされたクエリやORクエリを使用した複雑なクエリには、通常のメカニズムはありません。
• $ obj-> item [] = "value";の形式のクエリで配列プロパティ（複数のプロパティ）を入力する可能性はありません。 代わりに、今のところAddToArrayValue（ "item"、 "value"）を使用する必要があります。 この点を回避する方法は、まだ理解されていません。
• インフォブロック（1対1、1対多など）間に依存関係を作成するためのソリューションはありません。