この記事の目的は、
リモートファサードおよび
データ転送オブジェクトパターンの、1C 8.2環境のマネージドフォームでのコードの構造化への適用を示すことです。
はじめに
「管理フォーム」の概念と1Cプラットフォームの関連概念の簡単な説明から始めましょう。 プラットフォームの専門家は、このセクションをスキップできます。
2008年に、新しいバージョンの1C:Enterprise 8.2プラットフォーム(以降、マネージアプリケーションと呼びます)が利用可能になり、インターフェイスの作業層全体が完全に変更されました。 これには、コマンドインターフェイス、フォーム、ウィンドウシステムが含まれます。 同時に、構成内のユーザーインターフェイス開発モデルが変更されているだけでなく、クライアントアプリケーションとサーバー間で機能を共有するための新しいアーキテクチャも提案されています。
管理対象アプリケーションは、次のタイプのクライアントをサポートしています。
- シッククライアント(通常の制御された起動モード)
- シンクライアント
- Webクライアント
マネージアプリケーションは、新しいテクノロジで構築されたフォームを使用します。 それらは
管理フォームと呼ば
れます 。 移行を容易にするために、以前のフォーム(いわゆる通常のフォーム)もサポートされていますが、それらの機能は開発されておらず、シッククライアントのスタートアップモードでのみ使用できます。
開発者向けの管理フォームの主な違い:
- 構造の「ピクセル」ではなく、宣言的な説明。 要素の特定の配置は、フォームが表示されるときにシステムによって自動的に実行されます。
- すべてのフォーム機能は、 要件とコマンドの形式で説明されています 。 詳細はフォームが機能するデータであり、コマンドは実行されるアクションです。
- フォームはサーバーとクライアントの両方で実行されます。
- クライアントのコンテキストでは、ほとんどすべての種類のアプリケーションが利用できないため、インフォベースのデータを変更することはできません。
- メソッドまたはフォーム変数ごとに、実行場所(クライアントまたはサーバー)とフォームコンテキストへのアクセスを決定するコンパイルディレクティブを指定する必要があります。
フォームメソッドをコンパイルするためのディレクティブをリストします。
- &顧客
- &サーバー
- &コンテキストのないサーバー上
- &コンテキストのないサーバー上のクライアント
上記を説明します。 スクリーンショットは、開発モードでの管理フォームとそのモジュールの例を示しています。 宣言的な説明、詳細、コンパイルディレクティブなどを検索します。
以降の説明はすべて、図の右側、モジュールコードの構成方法、および効果的なクライアント/サーバー相互作用の実装を可能にする原則についてです。
問題を示す
1Cプラットフォームの新しいバージョンが積極的に使用され、1Cとその多くのパートナーの両方によって多くのソリューション(構成)がリリースされてから数年が経過しました。
開発者は、この間、フォームの作成中にクライアントとサーバーの相互作用の原則を統一的に理解し、新しいアーキテクチャの現実にソフトウェアモジュールを実装するためのアプローチは変更されましたか?
同じ典型的な構成のいくつかの形式のコード構造(フォームモジュール)を検討し、パターンを見つけてください。
構造とは、メソッドのグループ化とこれらのメソッドのコンパイル指令のために開発者によって割り当てられたコードのセクション(ほとんどの場合、これらはコメントブロックです)を意味します。
例1:
– – -
例2:
例3:
例4:
« »
実際、コード構造が欠落しているか、または控えめに言うと、フォーム8.1にあったものと似ています。
- 情報のない言葉「一般、サービス、支援」。
- Timidは、クライアントメソッドとサーバーメソッドを分離しようとします。
- 多くの場合、メソッドはインターフェイス要素「製品の表部分の操作、連絡先情報」によってグループ化されます。
- コードメソッドとグループの任意の配置。 たとえば、イベントハンドラーは、上部のフォーム、下部のフォーム、3番目のフォームがまったく選択されていないフォームなどになります。
- そして、これがすべて同じ構成内にあることを忘れないでください。
- はい、「General、Utility、Auxiliary」という単語が常に同じ場所にある構成がありますが...
なぜコード構造が必要なのですか?
- メンテナンスの簡素化。
- 学習の簡素化。
- 一般的/重要/成功した原則の固定。
- ...あなたのオプション
1Cの既存の開発標準が役に立たないのはなぜですか?
ITSディスクおよびさまざまな「開発者ガイド...」で公開されている、管理対象フォームの作成時に推奨される原則を見てみましょう。
- サーバー呼び出しの数を最小限にします。
- サーバーの最大コンピューティング。
- 非コンテキストサーバー呼び出しは、コンテキスト呼び出しよりも高速です。
- クライアントとサーバーの相互作用に基づいたプログラム。
- など
これらは絶対に正しいスローガンですが、どのように実装するのですか? 呼び出し回数を最小限に抑える方法、クライアントサーバーモードでプログラムすることはどういう意味ですか?
デザインパターンまたは世代の知恵
クライアントとサーバーの相互作用は、何十年もの間さまざまなソフトウェア技術で使用されてきました。 前のセクションで特定された質問への回答は長い間知られており、2つの基本原則に要約されています。
マーティン・ファウラーへの言葉、彼のこれらの原則の説明:
- ... リモートアクセスを目的とする可能性のある各オブジェクトには、特定の手順を実行するために必要な呼び出しの数を最小限にする詳細度の低いインターフェイスが必要です。 ...請求書とそのすべてのポイントを個別に要求する代わりに、1回の申し立てに対してすべての請求書ポイントを読み取り、更新する必要があります。 これは、オブジェクトの構造全体に影響します...覚えておいてください:リモートアクセスインターフェイスにはドメインロジックが含まれていません 。
- ...思いやりのある母親なら、私は間違いなく子供に次のように伝えます。「データ転送オブジェクトを書き込まないでください!」 1回の呼び出しで情報のいくつかの要素 -分散システムにとって非常に重要な手法。
1Cプラットフォームのテンプレートの例
管理フォームの開発時に開発者が利用できるアプリケーションプログラミングインターフェイスには、これらの原則の多くの例が含まれています。
たとえば、典型的な「粗面化された」インターフェースであるOpenForm()メソッド。
= ("1, 2, 3", 1, 2, 3); = (, );
v8.1で採用されたスタイルと比較してください。
= (); .1 = 1; .2 = 2; .();
管理されたフォームのコンテキストでは、多くの「データ転送オブジェクト」があります。
システム 定義のものと
開発者定義のものを区別でき
ます 。
システムは、1つ以上のフォームデータ要素の形式でアプリケーションオブジェクトをクライアント上でモデル化します。 フォームの詳細を参照せずに作成することは不可能です。
- DataFormStructure
- DataFormsCollection
- DataFormStructureCollection
- DataFormTree
データをアプリケーションタイプに、またはその逆に転送するためのシステムオブジェクトの変換は、メソッドによって実行されます。
- ValueInDataForms()
- DataFormsValue()
- CopyDataForms()
- ValueV必須フォーム()
- PropsFormsValue()
多くの場合、既存のソリューションを適応させるために明示的な変換が使用されます。 メソッドは、フォームデータコレクションではなく、値テーブルなどの入力パラメーターを期待する(機能を使用する)ことができます。または、メソッドはアプリケーションオブジェクトのコンテキストで定義され、フォームからの直接呼び出しではアクセスできなくなりました。
例1C v8.1:
例1C v8.2:
// = (""); .(); (, "");
開発者が構造を決定するデータ転送オブジェクトは、クライアントとサーバーの両方で使用可能なタイプの小さなサブセットです。 ほとんどの場合、次のパラメーターは、粗いインターフェイスメソッドのパラメーターと結果として使用されます。
- プリミティブ型(文字列、数値、ブール値)
- 構造
- コンプライアンス
- 配列
- アプリケーションオブジェクトへのリンク(一意の識別子とテキスト表現)
例:メソッドは、ステータスを変更するための注文のリストを受け入れ、エラーの説明をクライアントに返します。
& (, ) = (); // [][ ] (); = .(); …. , … (); .(, ()); ; ; ; // ()
コードを構成します
管理されたフォームのモジュールに反映されるべき主な目標とソリューションへのアプローチ。
- クライアントコードとサーバーコードの明確な分離。 実行時に、これらは相互に作用する2つのプロセスであり、利用可能な機能はそれぞれ大きく異なることを忘れないでください。
- リモートアクセスインターフェイスの明確な識別、クライアントから呼び出すことができるサーバーメソッド、およびできないサーバーメソッド リモートインターフェイスメソッドの名前は、接頭辞「Server」で始まります。 これにより、コードを読み取ってサーバーへの制御の移行をすぐに確認でき、コンテキストヘルプの使用が簡単になります。 公式の推奨事項(ITS)では、たとえば、サーバー上の注文のステータスを変更する()など、接尾辞付きの命名方法が提案されています。 ただし、すべてのサーバーメソッドをクライアントから呼び出すことができるわけではないことを繰り返します。したがって、論理的な可用性はコンパイルの場所よりも重要です。 したがって、接頭辞「Server」は、クライアントが使用できるメソッドのみをマークします。このメソッドの例は、Orders()のServerChangeStatusと呼ばれます。
- 読みやすさ。 それは好みの問題です。サーバー上でフォームを作成する手順とリモートアクセスメソッドでモジュールを開始するときに順序を取ります。
- 付随する。 新しいコードを追加する場所を明確に定義する必要があります。 重要なポイントは、コンフィギュレーターの調達方法によって自動的に生成され、モジュールの最後に追加されます。 ほとんどの場合、フォーム要素のイベントハンドラは自動的に作成されるため、各ハンドラをモジュール内の別の場所にドラッグしないように、対応するブロックが最後に配置されます。
以下は、これらの目標を実装するモジュールの基本構造です。
- グラフィックオプション-実行のメインスレッドを視覚的に表示します。
- テキストバージョンは、新しいフォームモジュールに構造をすばやく挿入するためのテンプレートデザインの例です。
//////////////////////////////////////////////////////////////////////////////// // <(c) ="<?"", >" ="<?"", ,"=dd.MM.yyyy">"/> // <> // <?> // </> //////////////////////////////////////////////////////////////////////////////// // //////////////////////////////////////////////////////////////////////////////// // //******* ******* & (, ) // //******* ******* //******* - ******* //////////////////////////////////////////////////////////////////////////////// // //////////////////////////////////////////////////////////////////////////////// // //******* - ******* //******* ******* //******* ******* //////////////////////////////////////////////////////////////////////////////// //
関連する質問
結論として、クライアントとサーバーの相互作用をプログラミングするときに考えることが役立ついくつかの領域の概要を説明します。
- リモートアクセスインターフェイスの実装オプション 。 非同期性、詳細度...
- キャッシング 1Cでは、彼らはアーキテクチャの決定に失敗し、一般的なモジュールの呼び出し方法のレベルでのみキャッシングを導入し、管理機能(関連性の時間、オンデマンドのリセット)を提供しませんでした。
- 暗黙的なサーバー呼び出し 。 技術的な機能を忘れないでください。クライアントでの「無害な」操作の多くは、サーバーにアクセスするためのプラットフォームを引き起こします。
- データのロードの事前/延期。