1Cでの管理対象フォームのプログラミングの基本原則

この記事の目的は、 リモートファサードおよびデータ転送オブジェクトパターンの、1C 8.2環境のマネージドフォームでのコードの構造化への適用を示すことです。





はじめに



「管理フォーム」の概念と1Cプラットフォームの関連概念の簡単な説明から始めましょう。 プラットフォームの専門家は、このセクションをスキップできます。



2008年に、新しいバージョンの1C:Enterprise 8.2プラットフォーム(以降、マネージアプリケーションと呼びます)が利用可能になり、インターフェイスの作業層全体が完全に変更されました。 これには、コマンドインターフェイス、フォーム、ウィンドウシステムが含まれます。 同時に、構成内のユーザーインターフェイス開発モデルが変更されているだけでなく、クライアントアプリケーションとサーバー間で機能を共有するための新しいアーキテクチャも提案されています。

管理対象アプリケーションは、次のタイプのクライアントをサポートしています。



マネージアプリケーションは、新しいテクノロジで構築されたフォームを使用します。 それらは管理フォームと呼ばれます 。 移行を容易にするために、以前のフォーム(いわゆる通常のフォーム)もサポートされていますが、それらの機能は開発されておらず、シッククライアントのスタートアップモードでのみ使用できます。

開発者向けの管理フォームの主な違い:



フォームメソッドをコンパイルするためのディレクティブをリストします。



上記を説明します。 スクリーンショットは、開発モードでの管理フォームとそのモジュールの例を示しています。 宣言的な説明、詳細、コンパイルディレクティブなどを検索します。





以降の説明はすべて、図の右側、モジュールコードの構成方法、および効果的なクライアント/サーバー相互作用の実装を可能にする原則についてです。



問題を示す



1Cプラットフォームの新しいバージョンが積極的に使用され、1Cとその多くのパートナーの両方によって多くのソリューション(構成)がリリースされてから数年が経過しました。

開発者は、この間、フォームの作成中にクライアントとサーバーの相互作用の原則を統一的に理解し、新しいアーキテクチャの現実にソフトウェアモジュールを実装するためのアプローチは変更されましたか?



同じ典型的な構成のいくつかの形式のコード構造(フォームモジュール)を検討し、パターンを見つけてください。

構造とは、メソッドのグループ化とこれらのメソッドのコンパイル指令のために開発者によって割り当てられたコードのセクション(ほとんどの場合、これらはコメントブロックです)を意味します。

例1:

    –   –   -          
      
      





例2:

         
      
      





例3:

                    
      
      





例4:

         « »
      
      





実際、コード構造が欠落しているか、または控えめに言うと、フォーム8.1にあったものと似ています。



なぜコード構造が必要なのですか?




1Cの既存の開発標準が役に立たないのはなぜですか?


ITSディスクおよびさまざまな「開発者ガイド...」で公開されている、管理対象フォームの作成時に推奨される原則を見てみましょう。



これらは絶対に正しいスローガンですが、どのように実装するのですか? 呼び出し回数を最小限に抑える方法、クライアントサーバーモードでプログラムすることはどういう意味ですか?



デザインパターンまたは世代の知恵



クライアントとサーバーの相互作用は、何十年もの間さまざまなソフトウェア技術で使用されてきました。 前のセクションで特定された質問への回答は長い間知られており、2つの基本原則に要約されています。



マーティン・ファウラーへの言葉、彼のこれらの原則の説明:





1Cプラットフォームのテンプレートの例


管理フォームの開発時に開発者が利用できるアプリケーションプログラミングインターフェイスには、これらの原則の多くの例が含まれています。

たとえば、典型的な「粗面化された」インターフェースであるOpenForm()メソッド。

  =  ("1, 2, 3", 1, 2, 3);  = (, );
      
      





v8.1で採用されたスタイルと比較してください。

  = (); .1 = 1; .2 = 2; .();
      
      







管理されたフォームのコンテキストでは、多くの「データ転送オブジェクト」があります。 システム 定義のもの開発者定義のものを区別できます

システムは、1つ以上のフォームデータ要素の形式でアプリケーションオブジェクトをクライアント上でモデル化します。 フォームの詳細を参照せずに作成することは不可能です。



データをアプリケーションタイプに、またはその逆に転送するためのシステムオブジェクトの変換は、メソッドによって実行されます。



多くの場合、既存のソリューションを適応させるために明示的な変換が使用されます。 メソッドは、フォームデータコレクションではなく、値テーブルなどの入力パラメーターを期待する(機能を使用する)ことができます。または、メソッドはアプリケーションオブジェクトのコンテキストで定義され、フォームからの直接呼び出しではアクセスできなくなりました。

例1C v8.1:

 //      ()
      
      





例1C v8.2:

 //       = (""); .(); (, "");
      
      







開発者が構造を決定するデータ転送オブジェクトは、クライアントとサーバーの両方で使用可能なタイプの小さなサブセットです。 ほとんどの場合、次のパラメーターは、粗いインターフェイスメソッドのパラメーターと結果として使用されます。



例:メソッドは、ステータスを変更するための注文のリストを受け入れ、エラーの説明をクライアントに返します。

 &  (, )  =  (); // [][ ]       ();   = .(); ….  ,     …  (); .(, ()); ; ;  ;  // ()
      
      







コードを構成します



管理されたフォームのモジュールに反映されるべき主な目標とソリューションへのアプローチ。



以下は、これらの目標を実装するモジュールの基本構造です。









 //////////////////////////////////////////////////////////////////////////////// // <(c) ="<?"", >" ="<?"", ,"=dd.MM.yyyy">"/> // <> // <?> // </> //////////////////////////////////////////////////////////////////////////////// //   //////////////////////////////////////////////////////////////////////////////// //   //*******    ******* &  (, ) //    //*******    ******* //******* -   ******* //////////////////////////////////////////////////////////////////////////////// //      //////////////////////////////////////////////////////////////////////////////// //   //******* -   ******* //*******  ******* //*******    ******* //////////////////////////////////////////////////////////////////////////////// //   
      
      







関連する質問


結論として、クライアントとサーバーの相互作用をプログラミングするときに考えることが役立ついくつかの領域の概要を説明します。




All Articles