「ブリッジ」パターン（双方向ブリッジ）またはMVC->「ビジネスエンティティ-視覚化-コントローラー」の正しい使用

背景



記事「Bridge / Bridgeの設計パターンの誤用」が起こったとき、聴衆は2つに分割されました。 それから私は、AがBを言わなかったと言って、それは正しくないと思った。 いいえ、言葉を拒否しませんが、「ブリッジ」パターンを使用した場所と方法を見つけました。 なぜなら それも誤解されており、別名「ディスクリプタ/ボディ」は誤解を招かないようです。



それでどこですか？ MVC（モデル/ビュー/コントローラー）の概念を使用する私のアナログで判明しました。



したがって、まず、「ビジネスエンティティ-視覚化-コントローラー」というバリエーションを紹介します。 すでに書きましたが、これに慣れている人は少ないと思います。 そして、「右の橋」がどこにあるかを確認します。



PS 私はここで信用の信用を与えられ、私はフライウェイトパターンの改善に関する別の記事を書くことを引き受けました -私はレポートを書きました 。







視覚化とビジネスロジックの分離



モデルビューコントローラーは、ソフトウェアアーキテクチャの最もよく知られた原則であり、アプリケーションデータモデル、ユーザーインターフェイス、および制御ロジックが3つの個別のコンポーネントに分割されているため、コンポーネントの1つの変更が他のコンポーネントへの影響を最小限に抑えます。 現在、本質的に歴史的な説明といくつかの側面は、2007年の「一般化されたモデルビューコントローラー」Sergey Rogachevの記事で説明されています。アクションで。



実際には、このモデルの使用には多くの問題が伴うため、このモデルに基づいて構築されたアプリケーションは、宣言にもかかわらず、柔軟性がなく、ほとんどつながりがありません。 ビジュアライゼーションをビジネスロジックから分離するというアイデアそのものが宣言されていますが、モデル、プレゼンテーション、コントローラー間の接続は完全に無効です。



すべての「ビジネスエンティティ」に視覚化があるわけではありませんが、原則として、コンテキストに応じて同じ「ビジネスエンティティ」を視覚化ありと視覚化なしの両方で使用できます。 ただし、このために機能が失われることはありません。 「ビジネスエンティティ」を視覚化せずに使用する場合、プレゼンテーションオブジェクトとコントローラオブジェクトを作成する必要はまったくありません。



しかし、モデル（いわゆるパッシブモデル）は、ビジネスロジックのないデータ（プロパティ、それらへのアクセス方法、データベースからの取得）としてのみ理解される場合があり、それを分離すると、そのようなモデルはそれ自体では役に立たなくなります。 古典的なパッシブモデル「Model-view-controller」の合理性を検証しましょう。ほとんどの場合、プレゼンテーションオブジェクトとコントローラーオブジェクトを作成しない場合、残りのモデルオブジェクトは完全に「麻痺」したままになります。つまり、機能しません。 したがって、このモデルの独立宣言はフィクションであることがわかります。



しかし、後に、モデルが実際にビジネスエンティティを意味する場合、データとビジネスロジックの組み合わせとして、アクティブモデルに関するアイデアが開発されました。 その後、すべてが正常に動作しますが、ビジネスロジックが視覚化クラスまたはコントローラーに残らないように、非常に注意する必要があります。



したがって、そもそも、オブジェクト指向のアプローチでは、実際のメソッド（ビジネスロジック）からのデータの分離は受け入れられません。これが行われないと、モデルは機能しなくなります（「麻痺」）。 したがって、混乱しないように、少なくとも用語を明確にする必要があります。また、「モデルビューコントローラー」ではなく、「ビジネスエンティティ-視覚化-コントローラー」と呼ばれるアーキテクチャの原則について説明します。 これまでのところ、私たちは言葉だけを変更し（これは非常に基本的であることがわかります）、パッシブMVCモデルを正しくないと見なすことを拒否しました。



次に、Model-View-Controllerモデルの宣言を見てみましょう。



ビューとコントローラーはモデルに依存しますが、モデルはビューやコントローラーに依存しません。 これは分離の重要な機能であり、視覚的な表現に関係なく、モデル、つまりアプリケーションのビジネスロジックを操作できます。



しかし、視覚的表現からのモデルの独立性に加えて、多くの場合、反対が必要です。 また、モデルからの視覚的表現の独立性も必要です。 そして、これはMVCの定義では不可能です。



だから最初の。 モデルに依存する単語表現は、次の2つのいずれかを意味します。

視覚化はモデル（ビジネスエンティティ）を作成（生成）し、クラスの観点から、視覚化はビジネスエンティティを集約します

（よりソフトなバージョン）コントローラーはモデル（ビジネスエンティティ）と視覚化の両方を作成します。 そして、コントローラーがこれらのオブジェクトへのリンクを処理する方法には2つのオプションがあります。

視覚化は、コントローラーとモデルの両方へのリンクを受け取ります。 視覚化は再びビジネスエンティティを集約します

視覚化はコントローラーへのリンクのみを受け取りますが、コントローラーにはモデルに直接アドレス指定されるデリゲートメソッドが含まれています。 正式には、視覚化はビジネスエンティティではなくコントローラーのみを集約しますが、間接的に（コントローラーがモデルを集約するため）再びビジネスエンティティの集約につながります。



少なくともあなたにはそれは奇妙に思えませんか？ ビジネスエンティティは、それ自体を視覚化する方法、または視覚化するかどうかをまったく決定できないことがわかります。 さらに、ユーザー（この場合、アプリケーション開発者）は、視覚化オブジェクトまたはコントローラーを作成する必要があり、何らかの奇妙な方法で、ビジネスエンティティを使用して視覚化またはコントローラーを操作する必要があります。 容認できる視覚化はまったく必要ないかもしれませんが。



したがって、私たちが最初に認識することは間違った決定です。 視覚化は、かなり具体的なアクションですが、ビジネスエンティティの機能の1つにすぎません。 したがって、ビジュアライゼーションオブジェクトを作成、集約し、いつどのオブジェクトでビジュアライゼーションするか、それを行うかどうかを決定する必要があるのはビジネスエンティティです。 ただし、ビジネスエンティティがインターフェイスを使用して視覚化したいデータフィールドを除き、視覚化オブジェクトはビジネスエンティティとコントローラについて何も知る必要はありません。



ただし、基本的な条件を満たす必要があります。



視覚化クラスには、ユーザーインターフェイスを操作するために必要なロジックのみが含まれます。 また、ビジネスエンティティクラスには視覚化コードは含まれていませんが、すべてのビジネスロジックが含まれています。



そのため、ユーザーインターフェイスを処理するコードとビジネスロジックを処理するコードを分離する必要があります。 一方、振る舞い（メソッド）は比較的簡単にパーツに分割できますが、データ（フィールド、プロパティ）ではできません。 データはグラフィック要素であり、ドメインモデル（ビジネスエンティティ）のデータと同じ意味を持つ必要があります。 したがって、データを含むフィールドを複製し、それらの同期を確保する必要があります（たとえば、TextBoxグラフィック要素の値は、ビジネスエンティティのフィールドの値と同期する必要があります）。 このような同期には、視覚化オブジェクトとビジネスエンティティ間の双方向通信が必要です。 したがって、データフィールドに関連して、これら2つのオブジェクトを分離することは基本的に不可能です。 ただし、第一に、データフィールドのみに制限することができ、第二に、視覚化オブジェクトに対して透過的にすることができます。



C＃は、視覚化に最新のWPFテクノロジーを使用し、バインディングメカニズムを提供します。 したがって、相互接続されるプロパティを示すためだけに残ります。 そして、ジレンマが発生します-これはどのような目的で行われるべきですか？ これがビジネスエンティティで記述されている場合、ビジュアライゼーションコードを含まないビジネスエンティティのルールクラスに違反しています。これがビジュアライゼーションクラスで記述されている場合、ユーザーインターフェイスを操作するために必要なロジックのみを含むルールビジュアライゼーションクラスに違反しています。 ただし、model-view-controllerモデルでは、これは多くの場合、視覚化クラスで指定されます。



しかし、私たちは異なる行動をとります。 3番目の、一見完全に冗長なクラス、つまりコントローラーを導入する理由の1つは、まさに上記のとおりです。 しかし、最初に、コントローラーそれ自体が何であるか、そしてそれがいつ作成されるかを明確にしてみましょう。 モデル「ビジネスエンティティ-視覚化-コントローラー」のコントローラーは、本質的にビジネスエンティティとその視覚化の間の相互作用のプロトコルです。 同時に、ビジネスエンティティが何らかの形で視覚化する必要があると判断した場合、特定の視覚化クラスのオブジェクトを選択して作成し、その後1つまたは別の対話プロトコル（コントローラー）を作成します。 同時に、コントローラーを作成するとき、彼女は自分と選択した視覚化への2つのリンクを彼に渡します。 その後、ビジネスエンティティは、理論的には（これを完全に達成することは実際には困難である可能性があります）、視覚化オブジェクトまたはコントローラー自体のいずれとも動作しなくなり、完全な独立性が確保されます。



初期化中のコントローラーはバインディングを規定し、視覚フィールドをビジネスエンティティのフィールドにリンクします。その後、これら2つの視覚化オブジェクトとビジネスエンティティは選択されたプロトコルに従って正式に同期されますが、それらの間には他の相互作用はありません。 このアプローチは透過的通信と呼ばれます。つまり、直接的な相互作用はありませんが、コントローラー（コントローラーに登録されているコード）に従って相互作用のみが発生します。



別のプログラミング言語を使用していて、バインディングを使用する方法がない場合は、Duplicate Observed Data [1]と呼ばれるリファクタリング手法に置き換えることができます。



ただし、自分でバインディングを実装することはできますが、それほど難しくありません。 最初に、モデルと視覚化の間のデータ同期は、独立したMySynhクラスによって実行される必要がある低レベルの機能であることを認識する必要があります。 書き方は？ コントローラーには、モデルと視覚化の両方へのリンクがあります。 彼はこれらのリンクをMySynhに渡します。 さらに、純粋に宣言形式では、視覚化フィールドA =モデルプロパティBの関係を純粋にテキストで規定します。 アクセスメソッドget（）、set（）は、モデルと視覚化の各プロパティに対して記述されます。このメソッドでは、新しい値を実際に割り当てることに加えて、ChangedFieldAという形式のイベントが生成されます。 これは、同期のためだけでなく、値を変更するロジックを呼び出すためにも必要です。 したがって、いずれにせよ。 残っているのは、MySynhが初期化されると、同期を処理すると伝えられたすべてのイベントをサブスクライブすることです。 値の変更の実際のイベントが発生すると、®は電話を受信し、サポートされている接続の種類についてデータベースで調べ、適切な接続を見つけます。 「リフレクション」（テキスト名でプロパティへのリンクを取得）を使用すると、新しい値が割り当てられます。



その結果、モデルと視覚化のデータは常に同期され、常に同じです。 そして、どちらにも互いへの参照はありません。 つまり 彼らは完全に独立しており、互いの存在を知りません。



今二番目。 透過的なデータ同期に加えて、動作（メソッド）の分離を保証する必要があります。 本質的に異なるロジックがあります-視覚化ロジック（たとえば、ボタンをクリックすると、1つまたは別のフィールドが表示または表示される）、およびビジネスロジック（たとえば、特定の値は入力されたデータに基づいて計算されます）。 ビジュアライゼーションクラスでビジュアライゼーションロジックを提供し、ビジネスエンティティでビジネスロジックをそれぞれ提供する必要があります。 これは必ずしも些細なことではありませんが、これにはかなりの注意を払う必要があります。 困難なのは、ユーザーからの信号が唯一のものであるということです。たとえば、ボタンを押すことであり、2つ以上の独立したメソッドを呼び出す必要があります。 同時に、分離の基本原則に違反しないように、視覚化オブジェクトからビジネスエンティティのメソッドを呼び出すことはできません。



ここでも、コントローラーを適用する必要があります。 ただし、データにbinding'a機能を使用した場合、この場合はイベントテクニックを使用する必要があります。 再度、初期化時に、コントローラーはビジュアルインターフェイスからの信号をビジネスエンティティのメソッドに関連付け、直接的な厳密な通信の代わりに、透過的な接続を取得します。



したがって、ビジネスエンティティと視覚化の間のリンクとしてコントローラーが必要です。 この場合、ビジネスエンティティと視覚化のほぼ完全に独立したクラスがあり、適切なコントローラーを選択することで、さまざまなビジネスエンティティと視覚化を任意の組み合わせで使用できます。 さらに、従来の「Model-view-controller」スキームと比較して、ビジネスエンティティに対して異なる視覚化を行うことができるだけでなく、特定の視覚化で異なる​​ビジネスエンティティを表示することもできます。 上記の問題は言うまでもありません。 このような組織では、両方向の視覚化とビジネスロジックを完全に分離できます。 また、ビジネスエンティティは、1つまたは別のコントローラを適用して1つまたは別のビジュアライゼーションと通信するだけで、ビジュアライゼーション自体を決定することもできます。



このテキストはわかりにくいかもしれません。 私の助けを借りて書いた一人の良い人がいます。おそらく私の考えについてのよりわかりやすい説明です。 コード例付き。



コントローラーはブリッジです



ここで「ブリッジ」を探すと、コントローラーには2つの「ボディ」への2つのリンクがあることがわかります。 1つは「ビジネスエンティティ」、2つ目は「視覚化」です。 最初の記事で議論したように、「抽象化と実装への分離」が有害な場合、なぜ彼はここに来たのですか。



そしてすべては、コントローラーが実装ではなく、抽象化でもないためです。 抽象化と実装は、「ビジネスエンティティ」にあるべきであるため、ここにまとめられています。 しかし、視覚化とビジネスロジック間の通信の特定のロジックは、コントローラーで取り出されます。 この通信の論理は、ブリッジにもたらすものです。 本質的に、視覚化は「ビジネスエンティティ」の実装の一部ですが、非常に特別です。 そして、それを分離するとき、異なる階層で「ユーザーインターフェイス」と「ビジネスロジック」を別々に開発することは非常に良いことです。 ただし、コントローラを介して接続します。 これは、ブリッジパターンの正しい使用方法です。 しかし、それは「双方向トラフィックのある橋」のようなもので、一方ではビジネスロジック（堅実）に、もう一方では「視覚化」に走ります