Openbiz は PHP メタデータ プログラミングを実装します

メタデータ プログラミングの考え方は、Java などの高級言語に由来しており、簡単に言うと、ビジネス ロジックを実装コードから分離し、XML などの記述言語のみを使用して、ビジネス間のマッピング関係を記述する必要はありません。実装コードを記述するだけでプログラミングが完了します。

Java から派生したメタデータ プログラミング機能

オリジナル データはソフトウェア アーキテクチャにおける高度なテクノロジの 1 つであり、より少ないコードを記述してより多くのことを実現できるようになり、ビジネス ロジックの再利用性が極限まで高まります。少し抽象的に聞こえるかもしれないので、私が提唱するメタデータ プログラミングの哲学を理解するのに役立つ実践的な例を見てみましょう。

Openbiz アーキテクチャにより PHP メタデータ プログラミングが可能

スクリプトレベルの PHP 言語は現在、Web 開発の主流言語の 1 つになっています。しかし、その起源はプロセス指向プログラミング言語 (シャベルがあった頃の php3 のことです) であるため、Python や Ruby のような言語ではなく、究極のオブジェクト指向言語です。オブジェクト。

この単純な背景と、おそらく PHP 自体がオープンソースで無料である理由に基づいて、PHP 言語の高度な拡張機能は常に .Net、Java、Objective C などの商用言語に後れを取っていることがわかります。 PHP5 がリリースされたとき、彼は「人類は今やオブジェクト指向だ!」と叫びました。Java、.Net、Cocoa は彼に「メタデータ プログラミングの概念はありますか? UI レベルで再利用可能なコントロールはありますか? なぜ Zend はそれを与えてくれないのですか?」と尋ねました。まだ服を着て、シャベルで遊びましょう」

Zend フレームワークの開発プロセスでは、常に基礎となるロジック コードの再利用に熱心に取り組んできました。たとえば、zend_cache、zend_mail、zend_gdata、zend_table は、実際に大量の基礎となるロジックの再利用を実現し、多くの微妙で複雑な問題を解決しました。 。

ここでは Zend の貢献を積極的に認めていますが、「兄弟、一歩前進してみませんか!」、いいえ!私たちの長兄は単純作業をするのが好きで、文学や芸術に携わるのが好きではありません。

最後は特にユーモラスです。Zend の絶え間ない努力の結果、兄はついに 1 つの複雑なもの (PHP) を別の複雑なもの (Zend Framework) に抽象化しました。 Zend の API インターフェイスは、PHP 自体の拡張に比べてそれほど単純ではありません。

ここで触れておかなければならないのは、イリノイ大学を修士号を取得して卒業し、モトローラ社のテクニカル ディレクターを務めた中国系アメリカ人であるロッキー スウェンです (私は 2003 年からずっと彼の技術的アイデアを支持していました)。 php4の時代に、コードを書かずにPHPでメタデータに基づいたプログラミングを実装できるようにするというコンセプトを提案し、9年を経て現在まで改良されているOpenbizフレームワークの原型を持っていました。

このコンセプトは当時私の目を輝かせました。Zend、CodeIgniter、および CakePHP を見ると、これらはすべて継承フレームワークであり、再利用可能なコード ライブラリのセットに相当するということです。解釈されたフレームワーク。「コンパイラー」の役割に相当します。 他の開発環境やフレームワークは、開発者が記述できるコードの量を減らすことに取り組んでいますが、Brother Rocky は、開発者にコードを記述させず、単純な XML 言語を直接使用してマッピング関係を記述し、プログラミングを完了すべきであると提案しました。

これらのプログラムを比較してみましょう

注文管理のデータオブジェクトを例に挙げます

PHP の従来のデータ オブジェクトの書き込み方法

クラスの順序DO

{

保護された $m_id;

保護された $m_client;

保護された $m_product;

protected $m_price;

protected $m_timestamp;

パブリック関数 create(){ … }

パブリック関数 delete(){ … }

パブリック関数 update(){ … }

パブリック関数 search(){ … }

パブリック関数 list(){ … }

}

OpenbizベースのPHPメタデータ記述方法

<ビズフィールドリスト>

すごいですね！これにより、将来の 2 つの可能性が見えてきます。プログラミングの主な作業が記述 XML 言語に基づいて行われる場合、将来的には完全な WYSIWYG プログラミング手法が登場する可能性が非常に高くなります。

もう 1 つの極端な例は、以下で説明するオブジェクト ファクトリの概念、つまり自動プログラミングかもしれません。

オブジェクトファクトリーのコンセプト、プログラムが書けるプログラム！

この概念について言及するたびに、私はインテリジェントなプログラミングまであとわずか数歩しか離れていないように興奮します。私の知る限り、この概念は .Net の内省によって最初に提案されました (中国語の翻訳は非常に奇妙です)。つまり、メイン プログラムが別の独立したサブプログラムを動的に作成し、動的にコンパイルし、オンデマンドでロードして破棄します (トランスフォーマー）を見たときはとても興奮しましたが、その後、基本的に誰もこのコンセプトについて言及しなくなりました。

私が Openbiz の基礎となるソース コードを読んで分析したのはさらに後になって、驚くべきことに PHP に基づくオブジェクト ファクトリの概念を発見しました。データ オブジェクトを例として、アイデアを分析します:

XML ベースのメタデータ ファイルは、「工場」に送信される組み立て命令とみなされます。このファイルは、このオブジェクトと層序データベースの間のマッピング関係だけでなく、このオブジェクトがどのように「組み立て」られるべきかを具体的に記述します。同じレベルの他のオブジェクトのマッピング関係 (1 対多の ORM など)

そのようなオブジェクトを作成するための生産指示を受け取った後、オブジェクト ファクトリは、説明に従って必要なオブジェクトを作成してアセンブルし、オブジェクト本体とステータスをシリアル化された方法でシステムにキャッシュして、再度呼び出しをトリガーするためのパフォーマンスを最適化します。メタデータ構成ファイルが変更されるまで、オブジェクトを動的に生成する必要があるのは 1 回だけです。つまり、無制限に使用できます。

このプログラミング ロジックに基づいて、一般的な変更と拡張の問題を解決します。

例: 顧客は、プロジェクトの承認中に、「連絡先管理モジュールを見て、誕生日と好みのフィールドを追加してもらえませんか。そうしないとバランスが崩れる可能性があります...」と、基礎となるデータ フィールドの変更を提案することがよくあります。

どうすればいいですか?

変更してください。 CRUD、リスト、検索はすべて変更する必要があります。

誰が変わる?

あなたがプログラムを書いたので、きっと変更したと思います。

Openbiz メタデータは異なります。ここでは、データ記述ファイルを変更するだけで、オブジェクト ファクトリがメタデータ構成ファイルの変更を検出し、オブジェクトとそれに関連するすべてのマッピング呼び出し (ORM) が自動的に書き換えられます。

特に複雑なビジネス上の偶然の一致を伴うシステムに直面すると、これらの上位レベルのオブジェクトの積み重ねられた呼び出し「あなたの中に私がいて、あなたの中に私がいる」という呼び出しが非常に複雑であることがわかります (そして非常に嫌なものです) ）。たとえば、ドキュメント変更レコードのビューでは、連絡先のこれらのフィールドも呼び出されます。このデータ構造の隅々まで正確に変更できますか?

これは人間の力を超えています!しかし、オブジェクト ファクトリはオンデマンドで作成されるため、それが可能です。

PHP 言語自体によるオブジェクトの処理には依然として欠陥があり、オブジェクトのライフサイクルは複数のビューにまたがることができません。ページ リクエストが実行されると、それに関連するすべてのリソースが自動的に破棄され、リサイクルされます。特にデータ オブジェクトには通常、データベース リンクとカーソル状態が含まれます。

Openbiz のセッション管理メカニズムは、オブジェクト ファクトリと連携してオブジェクトの永続的な状態を実現します。

オブジェクト ファクトリは、抽象クラスの MetaObject::setSessionData() インターフェイスを呼び出し、オブジェクトを配信する前にオブジェクトの状態を自動的に復元します。

このようにして、プログラムを作成するときに、ユーザー セッション全体を通じてユーザーが複数のビューに入力したデータを呼び出すことができます。たとえば、ユーザーが入力した情報は、現在のビューにデフォルト値として表示されます。

PHP での呼び出し構文の例:

$defaultValue =

BizSystem::getObject("package.do.DataObjName")

->getActiveRecord()

->フィールド名;

メタデータで Openbiz の SimpleExpression を使用するための構文例

DefaultValue="{@package.do.DataObjName[フィールド名].Value}"

/>

データ マッピングについて説明するだけでなく、Openbiz メタデータに基づいたビジネス ロジックについても説明します

このメタデータ プログラミング方法にすでに興味がある場合は、読み続けてください。

データ オブジェクトとデータ テーブルの間の関連付けマッピングをメタデータ化できるようになったら、他に何をメタデータ化できるでしょうか?

MVC の 3 層構造により、VIew や Form などの UI レベルの要素をメタデータベースにすることもでき、

などの XML 言語を通じて読み込みとトリガーの関係を記述することもできます。

このビューではどのフォームをロードする必要がありますか?

この編集フォームのテキスト コントロールは、どのデータ オブジェクトのどのフィールドにバインドされる必要がありますか?

このボタンが押されたとき、どのクラスのどのメソッドがトリガーされるべきですか?

CRUD (CRUD) などの一般的な論理フレームワークを下部に実装できることを想定しています。顧客が注文した後、私には電子メールで自動的に通知が送信され、流通部門にはテキストで通知が送信されます。メッセージ。このような比較的複雑なビジネス ロジックをメタデータに実装するにはどうすればよいでしょうか?

データ オブジェクト トリガーと構成可能なプラグイン サービス

この電子メールと SMS のトリガーは、UI レイヤーでは絶対に実装すべきではありません。注文がどこで生成されるかに関係なく、電子メール送信のロジックがトリガーされる必要があることを考慮する必要があるためです。したがって、このビジネス ロジックはデータ オブジェクトに結合する必要があります。つまり、注文が生成されるたびにこのロジックがトリガーされる必要があります。

電子メールおよびテキスト メッセージを送信するための一般的な再利用ロジックは、pluginService として定義できます。たとえば、電子メール送信サービスでは、受信者、タイトル、コンテンツは API パラメーター、電子メール送信アカウント、SMTP サーバー情報である必要があります。通常、業務システム全体と比べて大きな変更はなく、サーバーと連携してメールを送信する方法は、特定のオブジェクトロジックを再利用する必要があります。この設計の微妙な点については、次の記事で詳しく分析します。

今述べたロジックを実装するには、

を作成するだけです。

OrderDO_Trigger.xml のメタデータ ファイル

<PluginServiceName="OrderDO_Trigger" Description="" Package="" Class="doTriggerService" BizObjectName="collab.order.do.OrderDO">

 <DOTriggerTriggerType="INSERT"  >

  <TriggerConditionExpression="" ExtraSearchRule="" />

  <TriggerActions>

     <TriggerActionAction="CallService" Immediate="Y" DelayMinutes="" RepeatMinutes="">

        <ActionArgumentName="Service" Value="service.lib.userEmailService" />

        <ActionArgumentName="Method" Value="sendEmail" />

        <ActionArgumentName="RecipientEmail" Value="{@profile:Email}" />        

        <ActionArgumentName="EmailTemplate" Value="OrderConfirmEmail" />        

     </TriggerAction>

  </TriggerActions>

 </DOTrigger>

</PluginService>

「INSERT」イベントが発生すると、電子メール サービスが呼び出され、受信者はユーザーの電子メール アドレス、電子メールのコンテンツ テンプレートは OrderconfirmEmail になります

これまで、この典型的なビジネス ロジックは、コードを 1 行も記述することなくメタデータで記述されてきました。しかし、従来の開発手法を使用してこのような問題に対処すると、150 行を超えるコードの作業オーバーヘッドが避けられません。そして、可読性は必ずしもそれほど明確ではありません。

そういえば、私は Openbiz という鳥 (ロゴ) がとても好きで、PHP に翼を与えてくれたような気がします。

これで、私たち PHPer は Java に対して、PHP でビジネス ロジックを記述できるようになり、Java はデータ マッピングと構成情報にのみ使用できると言えるようになりました。

Openbiz メタデータ プログラミングと Zend 命名規則マッチング プログラミングの比較

この記事で紹介した Openbiz のメタデータのアイデアが唯一のものではありません。純粋にデータ オブジェクトの抽象化に関するものである場合、名前付けルール マッチング モードと呼ばれる、言及する必要があるもう 1 つの高度なモードがあります。これも Java の拡張機能です。 PHP 実装メソッドに変換されます。例:

$obj = new stdDataObj($tableName);

$obj->name='ABC';

$obj->attribute_1 = 123;

$obj->attribute_2 = 456;

$obj->save();

使用前にこのオブジェクトの構造を定義する必要はありませんが、とにかく、データを保存するときにデータベースと自動的に一致させます。 ただし、このロジックの拡張性はデータ ロジックに限定されているようで、ロジックを拡張するには従来の定義と宣言の方法を使用する必要があります。

重要なのは、これによって開発者の主な作業がコードから離れられるわけではありません。

この記事では、Openbiz フレームワークを例として、プログラミングの別の可能性を示します。

コードを極限まで単純化する方法から、コードは書かずにビジネスロジックのみを記述するようにしてください。

これが、オブジェクト指向の考え方における再利用の最大化の本質です。