マーティン・ファウラーの翻訳。 この記事では、UIアーキテクチャの一般的なアプローチについて説明し、MVC、MVP、プレゼンテーションモデル、フォームとコントロール、ハンブルビュー、パッシブビューなどのデザインパターンの詳細な説明を提供します。 この記事は脳をきれいにします。 ひとつのニュアンスを逃さないために、翻訳をすることにしました。



一般的に言って、私は長い間しゃがみ込んでいたので、すぐにすべてをやりたいと思っていました。 空に指。 時には坐骨神経痛に打たれ、プロジェクトのマイルストーンに近づき、長い箱で移管を延期しました。 または他の何かが干渉しました。 要するに、私は一度にすべてを習得しなかったので、消えないように、翻訳をパラグラフでアップロードすることにしました。 今、私は半分を移しましたが、半分は残っています。



私はプロの翻訳者ではないので、何かを誤解している可能性があります（さらに、場所によっては括弧内にメモを作成している場合もあります）が、いずれにしても元の記事を読む機会があります。 このような興味深い記事の翻訳が、誰かがスキルを向上させ、視野を広げるのに役立つことを願っています。

GUIアーキテクチャ

グラフィカルユーザーインターフェイスは、ユーザーと開発者の両方にとってソフトウェア開発環境のなじみのある部分になっています。 設計の観点からそれらを見ると、それらはシステム設計の特別な問題のセットを構成します-異なるが類似したソリューションを持っている問題。



私の関心は、プログラマーがリッチ（クライアント）クライアントを開発するために使用できる一般的で便利なテンプレートソリューションを特定することです。 設計検査の実装中と、より「永続的な」スタイルで記述された両方のさまざまなアーキテクチャを見ました。 これらのアーキテクチャには便利なソリューションがありますが、それらを記述することは簡単な作業ではありません。 たとえば、Model-View-Controllerを見てください。 多くの場合、この決定はテンプレートとして認識されますが、テンプレートに埋め込まれたアイデアが本質的に異なるためだけに、テンプレートとして認識してもあまりメリットはありません。 さまざまな人がさまざまなソースでMVCを読んで、さまざまな方法で彼のアイデアを認識していますが、これらのアイデアは同じ方法で「MVC」と呼ばれています。 これは、まるで人々が「壊れた電話」を通してそれを見つけたかのように、MVCの混乱と誤解につながります。



この作業では、いくつかの興味深いアーキテクチャソリューションを提供し、それらの最も興味深いプロパティのビジョンを説明します。 私はすべてを理解できるスタイルで説明することを望みます。



ある意味では、この作業を数年にわたるさまざまなUIプログラミングソリューションの歴史への遠足としてとらえることができます。 ただし、警告する必要があります。 アーキテクチャを理解することは、特にそれらの多くが変化したり死んだりする場合、単純な問題ではありません。 一部のアイデアを追跡することはさらに困難です。なぜなら、他の人が見るものとは異なる人が、自分の中で自分を見るからです。 特に、私が説明するアーキテクチャの詳細で徹底的な分析は行いませんでした。 私がしたことは、システム設計の一般的な説明として説明できます。 何かを見逃した場合、それは私がそれについて知らないことを意味します。 したがって、私の説明をガイドとして受け取らないでください。 さらに、重要でないものは特に簡略化したままにします。 私の主なタスクは、これらのソリューションの履歴ではなく、問題のソリューションを説明することであることを忘れないでください。



（ただし、MVCを学習できるように、Smalltalk-80の作業バージョンにアクセスできるという点で、私は少し矛盾しています。繰り返しますが、この研究は徹底的であるとは言えませんが、他の説明では説明できないソリューションの側面-他のアーキテクチャに精通していて、私が何かで重要だと思う場合、他のアーキテクチャの説明を唯一の真のものとして提示することを妨げます間違っているか何かを見逃した、それから私はそれについて知りたい また、私がお話しすることをより徹底的に分析することは、大学で勉強するための良い科目になると思います。）

フォームとコントロール

（ファウラーは、コントロールの概念を非常に熱心に使用しています。これは、「コントロール」として残したり、「コントロール」として翻訳したりできます。悲しいことに、ロシア語には「スラング」が使われていますが、「コントロール」という言葉はありません）あなたの目を苦しめないでください、それから私はコントロールを単に「要素」と呼びます。



この研究は、それ自体がほとんどの開発者に馴染みのあるシンプルなアーキテクチャから始めます。 共通の指定がないため、この作業の一般的なルールの目的のために、「フォームと要素」と呼びます。 このアーキテクチャは、主にVisual Basic、Delphi、Powerbuilderなどのクライアントサーバーアプリケーション開発環境によって提供されたため、よく知られています。 私のようなクールな建築ソリューションのファンによって拒否されているという事実にもかかわらず、それはまだどこでも使用され続けています。



それを理解する（および他のアーキテクチャソリューションを理解する）ために、すべての人に共通の例を使用します。 私が住んでいるニューイングランドでは、空気中のアイスクリームの量を追跡するための州プログラムがあります。 濃度が低すぎる場合、これは私たちが食べるアイスクリームの量が少なすぎることを意味し、ひいては経済と公序良俗に大きなリスクをもたらします。 （私はあなたがこの本のような他の本で見つけるよりも現実的でない例を使用したい）。



アイスクリームを監視するために、政府はすべてのニューイングランド州に特別な追跡ステーションを構築しています。 洗練された大気モデルを使用して、部門は各ステーションに目標値を割り当てます。 その後、スタッフはステーションに行き、アイスクリームの濃度を評価します。 以下のUIでは、ステーションを選択し、測定日（日付）と実際の濃度値を入力できます。 システムは、目標値と実際の値の差異を計算します。 さらに、実際の値が目標の90％未満の場合、偏差は赤で強調表示され、105％を超える場合は緑で強調表示されます。







図1：UI（例として使用します）



このビューから2つの重要な詳細を区別できます。 フォームはアプリケーション固有ですが、他のフォームに共通のコントロールを使用します。 ほとんどのGUI開発環境には、アプリケーションの開発時に使用できる共通要素の特定のセットがあります。 私たちは独自の要素を作成することができます（これは良いアイデアです）が、アプリケーションフォームと再利用可能な要素はまだ互いに異なっています。 つまり、作成された要素はさまざまな形式で使用できます。



フォームには2つの主要な責任があります。

• 画面レイアウト：フォームは画面上の要素の位置を決定し、それらを階層構造に結合します。
• フォームロジック：フォームは、要素にプログラムできない動作を定義します

ほとんどのGUI開発環境は、ドラッグアンドドロップ要素をフォームにドロップできるグラフィカルエディターなど、画面のレイアウトを決定する手段を開発者に提供します。 これは、原則として、レイアウトを作成し、フォーム上の要素の配置を簡単に調整するのに十分です（ただし、この方法は必ずしも最適ではありません-後でこれに戻ります）。



要素はデータを表示します-この例では、読み取り中です。 データは他のどこかから来る可能性が非常に高いです。 今回のケースでは、SQLデータベースからのものと想定しています。これは、前述の開発環境のメインデータソースであるためです。 ほとんどの場合、アプリケーションには使用されるデータの3つのコピーがあります。

• 最初のコピーはデータベース自体です。 このコピーは、実際のデータウェアハウス（データベース）のデータレコードを表示するため、それらを（データ） レコード状態と呼びます。 通常、さまざまなメカニズムを使用して、複数の人が一度に記録状態にアクセスできます。
• 2番目のコピーは、 レコードセットとしてアプリケーションメモリに保存されます。 ほとんどの開発環境は、一連のレコードを取得する簡単な方法を提供します。 それらのデータは、アプリケーションとデータベースの間の特定のセッションに関連するため、レコードセットをセッション状態と呼びます。 セッションの状態の本質的な特徴は、データベースに保存またはコミットするまでユーザーが操作するデータの一時的なローカルコピーを作成することです。同時に、セッションの状態はレコードの状態とマージされます。 組合ができる方法を詳細に分析したくありません。すでに[P of EAA]でこれを行っています。
• 3番目のコピーは、GUIコンポーネント自体に保存されます。 厳密に言えば、これはユーザーが画面に表示するデータなので、 画面状態と呼びます。 非常に重要なのは、UIがセッション状態と画面状態を同期する方法です。

画面状態とセッション状態の同期は非常に重要なタスクです。 それを解決できるツールはData Bindingです。 データバインディングの考え方は、レコードセット内のアイテムデータまたはレコードデータで発生した変更が、すぐにお互いに広がるということです。 つまり、画面に現在の濃度を入力すると、「テキストボックス」要素はレコードセット内の対応するデータレコードの列の値を更新します。



データバインディングの実装は非常に複雑です。たとえば、要素を変更するとデータセットが変更され、要素が更新され、データセットが更新され、要素が更新されるなど、このようなサイクルを回避する必要があるためです...サイクル-画面が開いたときにのみ、セッション状態から画面状態にデータをロードします。その後、画面の変更がセッション状態に反映されます。 画面が開いたときにセッションの状態を更新することはまれであり、必要ありません。 その結果、データバインディングは完全に双方向ではない可能性があります。初期データの読み込みと、セッション状態への画面変更の処理に制限される場合があります。



一般的に、データバインディングは、クライアント/サーバーアプリケーションのほとんどの機能を実装します。 実際の濃度の値を変更すると、列の値が更新されます。 別のステーションを選択しても、レコードセット内の選択されたレコードが変更され、他のアイテムが更新されます。



基本的に、説明されている動作は、アプリケーションフレームワークの開発者によって既に実装されており、プログラマの基本的なニーズを迅速かつ簡単に満たすためのツールを提供および提供しています。 特に、1つの方法は、通常「プロパティ」と呼ばれるコントロールの特性のいくつかを明示的に設定することです。 この要素は、データセットの列の文字列名を読み取ります。この文字列は、開発者が単純なプロパティエディターを介して指定し、それに添付されています。



適切なパラメーター化でデータバインディングを使用すると、アプリケーションのほぼすべての機能を実装できます。 ただし、データバインディングはすべての機能を実装することはできません。ほとんどの場合、アプリケーションにはパラメーター化オプションに該当しないロジックがあります。 この場合、偏差の計算は、データバインディングでは実装できないものの例です。そのような機能はアプリケーション固有であり、フォーム自体に実装されているためです。



それを実装するために、フォームはユーザーが実際の濃度の値を入力し終えたことを知る必要があり、これはコントロールがフォームの動作を引き起こす必要があることを意味します。 このロジックは、制御の反転を意味します。 （オリジナルでは、「これは、クラスライブラリを取得し、Inversion of Controlが関与しているときにそれを呼び出すことで使用するよりも少し複雑です。」



この問題を解決するにはさまざまな方法があります。 通常、クライアント/サーバーアプリケーション開発環境にはイベントプレゼンテーションシステムがあります。 各コントロールには、トリガーできるイベントのリストがあります。 外部オブジェクトには、イベントに関心があることを要素に伝える機能があります。 この場合、要素イベントが発生すると、要素はそのようなオブジェクトに制御を移します。 基本的に、この説明はObserverパターンの再定式化にすぎず、フォームは要素に従います。 フォームの開発者は、アプリケーションフレームワークを使用して、イベントの発生後に実行されるメソッドにコードを記述することができます。 このメソッドとイベント間の接続が発生する方法は、特定のプラットフォームによって異なり、この場合は重要ではありません。 重要なことは、そのようなメカニズムが存在し、機能することです。



フォームが制御されると、必要なことは何でもできます。 彼女はいくつかのアクションを実行し、コントロールを変更し、データバインディングに基づいて、セッション状態に変更を戻すことができます。



データバインディングは常に利用できるとは限らないため、このようなメカニズムも必要です。 世界には多くのウィンドウコントロールがあり、それらのすべてがバインディングをサポートしているわけではありません。 バインディングがない場合、フォームは状態間のデータ同期を処理する必要があります。 特に、彼女自身がデータセットからデータを引き出して、コントロールに入れることができます。 データを保存し直したい場合は、「保存」ボタンを押すイベントと同じ方法で保存できます。



データバインディングが利用可能な場合、現在の濃度値がどのように編集されるかを見てみましょう。 フォームには、コントロールへのリンクが保存されます。 各要素には独自のリンクがありますが、実際の値、偏差値、および目標値のテキストフィールドにのみ興味があります。







図 2：フォームと要素のクラス図



テキストフィールドは、テキストが変更されたときにイベントを通知します。 初期化段階で、フォームはそれ自体を収集し、イベントにサブスクライブし、そのメソッドをバインドします-ここでは、 actual_textChanged



。







図3：テキストを変更するためのシーケンス図



ユーザーが実際の濃度の値を変更すると、テキストフィールドがイベントを発生させ、アプリケーションフレームワークの特別な魔法を使用して、 actual_textChanged



フォームactual_textChanged



実行します。 このメソッドは、フォーム要素から実際の値と目標値を受け取り、計算を実行して、差異テキストフィールドに偏差を設定します。 また、結果の値を強調表示する色を計算し、強調表示します。



これで要約できます：

• プログラマーは、機能を使用してアプリケーションの詳細に依存するフォームを開発しますが、すべてのフォームに共通のコントロールを使用します。
• フォームは、コントロールのレイアウトを記述します。
• フォームは、コントロールのイベントを監視して処理します。
• 単純なデータ変更は、データバインディングを使用して同期されます。
• 複雑な変更は、メソッド（イベントハンドラー）で行われます。

次の部分はこちらです。