こんにちは。 また私です。 habrakatの中には、Martin Fowlerの記事の別の段落の翻訳があります。



今回はMVCテーマを中心に。 ファウラーは彼について非常に人気がありました。 私は一般的に翻訳しようとしました:)これで、誰もが書かれたバッグのようにMVCを身に着けている理由を理解できます。 ちなみに、ファウラーは正しいです-多くの人々と多くの人が独自の方法でMVCを認識しています。 Fowler自身が、Smalltalkプラットフォームで機能するオリジナルのMVCについて書いています。 非常に有益です。



前の部分はこちらです。 元の記事はこちらです。 Fowlerは一般的な問題の例を概説しているため、最初の部分を読むことを強くお勧めします。 このタスクについて読んでいない場合、それが何であるかが少し不明瞭になります。



怒り、一緒になって、翻訳の次の部分を書きます。

モデルビューコントローラー

モデルビューコントローラー。 おそらく、UI開発で最も一般的なパターンはModel-View-Controller（MVC）です。 さらに、ほとんどの場合、最も誤解されています。 私は、MVCと呼ばれるものを見た回数をすでに失いましたが、MVCは自分自身を見つけませんでした。 率直に言って、これは古典的なMVCが最近の太った顧客にもはや適さないからです。 MVCがどこから来たのか見てみましょう。



MVCを掘り下げる前に、彼がソリューションの規模に関係なくUIの問題の解決に真剣に取り組む最初の試みの1人であることを覚えておくことが重要です。 70年代、「グラフィカルユーザーインターフェイス」の概念はあまり一般的ではありませんでした。 上で説明したShapes and Elementsテンプレートは、MVCよりも後に登場しました。 私は主にそれがより単純であり、常に言葉の良識ではないため、それを説明しました。 すでによく知られているアイスクリーム濃度の例でSmalltalk 80 MVCを見ていきます。 同時に、私は自分自身にいくつかの自由を認め、Smalltalk 80プラットフォームについて説明します。



MVCアイデアの核心は、後続のすべてのフレームワークの核心アイデアであり、私が「 分離プレゼンテーション 」と呼んでいるものです。 別のビューの意味は、現実世界を反映するドメインオブジェクトと、画面上のGUI要素であるプレゼンテーションオブジェクトの間に明確な線を引くことです。 ドメインオブジェクトは完全に独立しており、プレゼンテーションを参照せずに動作する必要があり、複数の表現をサポートする必要があります。同時にも可能です。 ちなみに、このアプローチはUnix文化の重要な側面の1つでもあり、今日でもコマンドラインとグラフィカルインターフェイスの両方で（同時に）多くのアプリケーションで作業することができます。



MVCでは、モデルはドメインオブジェクトを指します。 ドメインオブジェクトはUIとは関係ありません。 MVCで濃度と測定値を使用して例をレイアウトするために、関心のあるすべてのフィールドを持つ読み取りオブジェクトをモデルとして使用します。 （ご覧のとおり、リストボックス要素があるとモデルが少し複雑になりますが、しばらくはこのニュアンスを無視します）。



MVCでは、 レコードのセット （ Record Set ）を扱った「フォームと要素」とは対照的に、ドメインモデル（ Domain Model ）の通常のオブジェクトを参照します。 これは、2つのテンプレートの設計上の違いの1つです。 「フォームと要素」では、ほとんどの人がリレーショナルデータベースのデータを簡単に操作したいのに対し、MVCは通常のSmalltalkオブジェクトを操作することを前提としています。



MVCのプレゼンテーション部分は、プレゼンテーションとコントローラーの2つの要素から作成されます。 コントローラーの仕事は、ユーザー入力を取得し、それをどう処理するかを把握することです。



ここで、この例では、ビューとコントローラーが単数形で存在しないことを強調する必要があります。 画面上の各項目、画面上の各コントロール、および画面自体に対して、ビューとコントローラーのペアが必要です。 したがって、この例では、ユーザー入力に対する最初の反応はコントローラーの共同作業であり、これは現在どの要素がこのデータを受信して​​いるかを決定します。 このような要素は、実際の集中度のテキストフィールドになります。 このテキストフィールドのコントローラーは、入力されたデータを処理します。







図4.モデル、ビュー、コントローラー間の基本的な関係。 （実際、ビューとコントローラーは互いに直接関連している可能性があるため、基本と呼びます。ただし、開発者はこの接続をほとんど使用しません。）



その後の開発環境と同様に、Smalltalkプラットフォームは、再利用可能な汎用UIコンポーネントを作成する機能を提供しました。 私たちの場合、そのようなコンポーネントはビューとコントローラーのペアになります。 両方とも汎用クラスです（ いわゆる構成に応じて-およそTransl。 ）。 さまざまなアプリケーションで使用できるように、一般化が必要です。 1つは評価ビューです。これは画面全体の役割を果たし、より単純な要素の場所を決定します。 この順序は、「フォームと要素」の順序と似ています。 ただし、「フォームと要素」のフォームオブジェクトとは異なり、MVCには評価コントローラーにテキストフィールドイベントハンドラーがありません。







図5.アイスクリーム濃度の例のMVCバージョンのクラス。



実際の値を入力するユースケースを検討してください。 実際の値のテキストフィールド要素の構成は、モデル（測定オブジェクト）との接続で構成されます。 要素でテキストが変更されたときにモデルで呼び出す必要があるメソッド。 画面を初期化すると、選択されたメソッドは「#actual」になります（行の先頭の「＃」文字はインターンされた行を示します）。 テキストが入力されると、コントローラーは測定オブジェクトで指定されたメソッドを再帰呼び出しします（実際のフィールドの値を変更します）。 実際、データバインディングでもまったく同じメカニズムが発生しました。 コントロールは、基礎となるオブジェクト（レコード）に関連付けられ、どのメソッド（つまり列）を制御するかを認識しています。







図6.実際の値フィールドの変更



そのため、結果のソリューションには一般的なブラウジングオブジェクトはありません（イベントハンドラーを持つフォームオブジェクトを思い出してください）。 代わりに、コントロールは（フォームオブジェクトではなく）動作が定義されているモデルを見落とします。 つまり、インジケーターの差（分散）の値を決定する必要がある場合、モデルはこれ自体に対処します。



ブラウザはMVCにあります。 実際、これはMVCによって生成されたアイデアの1つです。 この例では、すべてのビューとコントローラーがモデルを見落としています。 モデルが変更されると、表現が反応します。 実際の値のテキストフィールドの表現は、測定オブジェクトが変更されたという情報を受け取り、その後、特定のテキストフィールド（この場合は#actual）のアスペクトとして定義されたモデルメソッドを呼び出し、その値をフィールドに設定します。 （テキストボックスの色についてもほぼ同じことが起こりますが、すぐに説明する独自の「ゴースト」があります。）



テキストフィールドコントローラー自体は、テキストフィールドビューに値を公開しないことに注意してください。 モデルを更新し、ブラウザメカニズムが他のオブジェクトの更新を処理できるようにします。 このアプローチは、フォームオブジェクトを更新するとコントロールが更新され、データバインディングを介して基になるレコードセット（レコードセット）が更新される「フォームと要素」とは異なります。 これら2つのアプローチをテンプレートに選択し、それに応じて名前を付けます： Flow SynchronizationとObserver Synchronizationです。 彼らはスクリーン状態とセッション状態の間で同期する異なった方法について説明します。 「フォームと要素」は、アプリケーションの呼び出しフローを介して、直接アクセスして直接更新する必要があるさまざまな制御要素とデータを同期します。 MVCはモデルの更新を介して同期し、ブラウザーとの関連付けを介してコントロールの表現を更新することに依存しています。



アプリケーションにデータバインディングがない場合、ストリームの同期はより顕著になります。 この場合、アプリケーションは重要な段階（アプリケーションフロー）の1つで明示的に同期する必要があります。たとえば、画面を開いたとき、または「保存」ボタンを押したときなどです。



ブラウザーを介した同期 （ Observer Synchronization ）の結果の1つは、突然ユーザーが何らかの方法で変更した場合（つまり、別の要素）、コントローラーが他の要素の変更を認識しないことです。 「Forms and Elements」のフォームオブジェクトは、何かが変更された場合（フォームの複雑なレイアウトでは非常に時間がかかる可能性があります）、画面の状態の整合性を慎重に監視する必要があります。



この便利な利点は、同じモデルオブジェクトを見落とす複数の画面が開いている場合に特に便利です。 MVCの典型的な例は、テーブル、たとえばデータを含む画面と、このデータのさまざまなグラフのいくつかのウィンドウです。 テーブルのあるウィンドウは、他のウィンドウが開いていることを知る必要はありません。 モデルを更新するだけで、 Observer Synchronizationが残りを行います。 Stream Synchronizationを使用すると、更新するために他のウィンドウが開いていることを何らかの方法で知る必要があります。



Observer Synchronizationのすべての利点には、1つの欠点があります。 オブザーバー同期の問題はブラウザー自体にあります。コードを見ると、何が起こっているのかわかりません。 Smalltalk 80に実装されている例を理解したとき、この不便さを非常にはっきりと思い出しました。 一部のコードのセクションで何が起こるかを知ることはできますが、ブラウザーがビジネスを始めるとすぐに、次に何が起こるかを理解するためにトレーサーとデバッガーが必要です。 ブラウザーの動作は暗黙的であるため、理解や議論が困難です。



提示された図から、状態同期へのさまざまなアプローチを観察できます。 ただし、MVCの最も重要で影響力のある違いは、 Separated Presentationの使用です。 実際の値と目標値の間の偏差の計算は、ドメインモデルの動作であり、UIに依存するべきではありません。 したがって、この動作をシステムのドメイン層（測定（読み取り）の対象であるその層）に実装します。 偏差を計算する方法は、測定オブジェクトにとって絶対に論理的であり、ユーザーインターフェイスについてはわかりません。



しかし、今、私たちは物事の現在の状態のいくつかの合併症を考慮することができます。 MVC理論について話したときに私がすり抜けた2つの不快な領域があります。 最初の問題領域は、差異テキストフィールドへの色の割り当てです。 このロジックは、偏差値を強調表示する色がその一部ではないため、ドメインオブジェクトに完全に属しているわけではありません。 それにもかかわらず、そのようなロジックの一部はそれにもかかわらず一部です。 たとえば、偏差の品質の評価：良好（5％以上）、不良（10％未満）、正常（その他すべての値）。 評価計算はドメインロジックです。 テキストフィールドの色付けはプレゼンテーションロジックです。 問題は、プレゼンテーションロジックを配置する場所です。 通常のテキストフィールドのロジックの一部ではありません。



Smalltalkの最初の開発者はこの問題に直面し、この問題の解決策も提案しました。 上記のソリューションは、ドメインロジックの「純度」に違反するため、汚れています。 私はランダムな「汚染」行為を認め、それが習慣にならないようにしています（ これは、ファウラーが冗談を言っている-およそTransl。です ）。



「フォームと要素」と同じ方法でこの問題を解決することもできます-評価画面で偏差テキストフィールドの表示を見落とすことができます。 値が変更されると、画面が応答し、テキストフィールドに色が割り当てられます。 しかし、そのようなソリューションにはブラウザーメカニズムの使用が含まれます。そして、それらを掘り下げるほど、（指数関数的に）それらとの作業がより複雑になり、異なる表現間の不要な接続の数も増加します。



新しいタイプのUI要素を開発したいと思います。 この要素の動作の特徴は、ドメインオブジェクトに推定値を要求し、値と色の内部テーブルと比較し、テーブルから取得した色で強調表示することです。 テーブルとドメインオブジェクトの値の要求は、それ自体のアセンブリ段階での評価の提示によって割り当てられます。 まったく同じ方法で、値のアスペクトがそれに続くようにテキストフィールドに割り当てられます。 テキストフィールドから継承する簡単な方法があれば、このアプローチは非常にうまく機能します（新しいビヘイビアを追加します）。 そのような方法があるかどうか-それは、適切に設計されたコンポーネントが継承をサポートするかどうかに依存します-Smalltalkでは非常に簡単で、他の環境ではより複雑になる可能性があります。







図7：色の定義をサポートするテキストフィールドクラスの継承を使用します。



最後の仕上げは、画面上の要素に従う特別なドメインオブジェクトの作成ですが、同時にそれに依存しません。 つまり、画面のモデルを作成します。 以前に測定オブジェクトに対して呼び出されたメソッドは、モデルによって測定オブジェクトに委任されます。 また、色決定などの「UIのみ」のメソッドも定義します。







図8：プレゼンテーションロジックの処理でのプレゼンテーションモデルの使用。



提案されたソリューションは多くの場合に機能し、後で見るように、Smalltalk開発者が従う一般的な手法になりました。 ビューレイヤー用に設計されている（ビューレイヤーの一部である）ため、ビューモデル（）と呼びます。



プレゼンテーションモデルは、プレゼンテーションロジックの別の問題-プレゼンテーション状態の問題を解決します。 MVCの基本概念は、ビューステートがモデルステートから継承されることを前提としています。 どのステーションがリストで選択されているかを判断する方法は？ プレゼンテーションモデルは 、このような状態を配置する場所を提供することにより、この問題を解決します。 データが変更されたときにのみ押すことができる「保存」ボタンがある場合、同様の問題が発生します。この状態は、モデル自体ではなく、モデルとの相互作用によって決定されます。



今、MVCの特性を特定する時が来たと思います。

• プレゼンテーション（ビューとコントローラー）とドメインモデル- 分離プレゼンテーションを明確に分離します。
• UI要素をコントローラー（ユーザー入力に対応）とビュー（モデルの状態を表示する）に分離します。 コントローラーとビューは、（ほとんどの場合）モデルを介してのみ直接対話する必要があります。
• ビュー（およびコントローラー）がモデルを見落とすようにします。 これにより、複数のウィンドウを相互に直接対話することなく常に最新の状態にすることができます-ブラウザーを介した同期 （ Observer Synchronization ）。

継続する。