今日は、情報システムのアーキテクチャ、特に、伝統的にMVCに起因するロジック、データ、ディスプレイの分布に対する多様なアプローチについての私の考えを共有したいと思います。
過去2週間にわたって、12人の使い慣れたプログラマーとの会話の中で、MVCのイメージがまったく異なることを誰もが知っていました。 正反対の見解になりますが、何らかの理由で、誰もがMVCであり、そのように見えるべきだと主張し、誰もがそれを見ると確信しています。
違いは何ですか？ これを理解するために、MVCのタスクを定式化しましょう。
1.モデルをスクリーニングします。つまり、モデルがアプリケーションの技術的な実装、ユーザーインターフェイス、ネットワークプロトコル、データベースの操作、さらにはシステムアーキテクチャについても「認識」していないことを確認します。 モデルは対象分野を反映し、技術の範囲外である必要があります。
2.プレゼンテーションレイヤーを分離する -同じモデル用に複数のビューを作成できることを意味します。たとえば、異なるユーザーデバイス、ブラウザー、モバイルプラットフォーム、ウィンドウアプリケーション用に並行して存在できます。 また、これにより、GUIプログラマー、さらには表示テンプレートを作成できるがコードには入らないデザイナーとの分業を導入して、作業を並列化することができます。
これですべてです。システムには2つの部分があり、それらが互いに依存しにくいことを確認する必要があります。 また、モデルは表現を「認識」してはならないため、3番目のエンティティが導入されます。システムの両方の部分を「認識」し、大まかに言えば、それらを呼び出すことができるコントローラーです。 これが混乱の始まりです。
意見が一致しない最初の点は、アプリケーションロジックの場所です。 すべてのロジックをモデルに入れてコントローラーの薄いレイヤーを作成するものもあれば、反対に、コントローラーの機能を向上させてデータのみをモデルに残すものもあります。 この場合、コントローラーには、サブジェクト領域に属することを示す名前が「Manager」、「Dispatcher」、「Logic」、「Controller」などの接頭辞を持つクラスで埋められます。 実際には、2つのオプションがあります。コントローラをシステムのコアにするか、プロキシレイヤにするかです。 ただし、ビューがモデルに非常に密接に接続されているため、モデルに座標、動作、レンダリング機能が直接含まれ、コントローラーが蒸発する場合、タスクのクラス（高度な視覚化とゲームを備えたグラフィカルアプリケーション）もあります。 これはMVVM（Model-View-ViewModel）と呼ばれ、後で判明したように、データ入力、機器管理などに関連する幅広いアプリケーションにも便利です。
2番目の不一致は、誰がデータベースを操作するかについてです。 誰かがモデルにデータの要求を入れて、モデル自体が「上昇」してそれを保存する方法を知っている必要があると言います。他の人はコントローラーにDBMSへの呼び出しを置き、他の人はデータベースを操作するためにシステムの別のコンポーネントを割り当て、それを呼び出しますリポジトリ」、「リポジトリ」、または「ORM」（つまり、オブジェクトリレーショナルマッピング）。 ORMは、コントローラーの要求に応じてモデルオブジェクトを生成し、その要求に応じて、オブジェクトをデータベースと保存、変更、または同期できます。
3番目の違いは、インターフェイスロジックを実装する場所です。これは、最も単純なアプリケーションでのみ忘れることができます。 プレゼンテーション層に配置できますが、一部の人にとっては概念的ではないようで、コントローラー内の場所を見つけます。 したがって、ユーザーインターフェイスの各動きで、制御はコントローラーに落ちます。 Webアプリケーションの場合、ビュー自体は最小のユーザーアクションにも応答できないため、これによりページのオーバーロードまたは一定のAJAXリクエストが発生します。
最後に、相違点の最後のポイントは、MVCアーキテクチャアプローチと3層アーキテクチャとの混乱に現れています。DBMS-ApplicationServer-Clientは、特に古い世代の開発者の間で長年にわたって定着してきました。 実際、MVCと3リンクは同じものではありませんが、並行して存在できます。 たとえば、Webアプリケーションでは、3つすべてのリンクをサーバー上に配置でき、完成したページのレンダリングのみがWebブラウザーで行われます。 クライアントがプレゼンテーションレイヤーを完全または部分的に実装するJavaScriptクライアントアプリケーションを実行する場合のもう1つのオプションは、より現代的です。 これらの目的のために、JavaScriptテンプレートも登場しました。 ただし、HTMLを完全に拒否し、ページを単一のJavaScript接続タグに削減しない限り、プレゼンテーションをクライアント側のブラウザに完全に転送することはできません。 これは過激主義です。SEO、モバイルブラウザ、無効なJavaScriptについても話していない。
したがって、誰もがMVCをさまざまな方法で想像し、この記号の下で完全に異なるアーキテクチャを実装します。MVC、MVc、mvC、mVCなどを任意に示します。 これはすべて、タスク自体に矛盾があるためです。 モデルとプレゼンテーションを独立させるために、データ、ロジック、マッピングを分離する必要はまったくありません。 これらはまったく異なるものです。 分離された各リンクには、データ、ロジック、マッピングが含まれます。たとえば、データベース内のデータロジックとストアドプロシージャ。 ユーザーインターフェイスにロジックを表示します。 ビジネスロジックまたはモデルロジック。 データは、ユーザーインターフェイスとコントローラーの両方に含まれています。 インターフェースはインターフェースであるだけでなく、モデルとコントローラー間のユーザーインターフェースでもあります。
モデルをコントローラーから分離することは不可能であることがわかりましたか？ 可能ですが、このためには、データ、ロジック、表現の分離を放棄する必要があります。 逆説的に、MVCは、Model、View、およびControllerが異なる抽象化レベルで実装されている場合にのみ機能します。 モデル -データとドメインのロジックの両方を含む必要があり、有能なオブジェクト指向プログラミングでは、「ドメインオブジェクト」または「現実世界のオブジェクトの表示」の概念と一致する必要があります。 モデルは、まずモデリングです。これには、情報モデル、論理モデル、および一部のタスクの視覚化モデルも含まれます。 サブジェクト領域のサブジェクトは、データベースに格納され、プログラムモジュール間およびネットワークを介して送信される方法を知る必要はありません。 仮想マシンのようにアプリケーションで実行され、理想的には、システム間でも移植可能でなければなりません。 そのために、スクリプト化されたインタープリタ型言語でモデルロジックを記述することを強くお勧めします（個人的な好みはJavaScriptです）。 スクリプトはネイティブ言語コードにコンパイルすることも、直接バイトコードにコンパイルして長期間キャッシュすることもできるため、モデルの速度は除外されません。 ユーザーインターフェイスについては、モデルの一部が常に含まれます。JavaScriptの場合、一部はサーバー上、一部はクライアント上で、ビジネスロジック、検証、モデルなどを実行できます。 一部はクライアントのみまたはサーバーのみにあり、一部は何度も書き直さずにそこにあります。 ビューとは何ですか？ また、 Viewはレンダラー（Webアプリケーション-ブラウザー用）に加えて、ビジュアルコンポーネントのライブラリ（古いdelphistを除く）、およびテンプレートとスタイルです。
コントローラーには何が残っていますか？ コントローラは、ドメインオブジェクトが実行される仮想マシンです。 コントローラーは、アプリケーションごとに書き換える必要はありません。アプリケーションフレームワークです。 さらに、コントローラーの一部はサーバー側で機能し、一部はブラウザーで機能します。 コントローラーはサーバー側のモデルからデータを取得し、ネットワーク経由で送信します。 一方、ブラウザーでは、コントローラーがデータをキャッチして視覚化のために送信し、ユーザーのアクションごとにネットワーク上でデータを駆動しないようにクライアントに必要なモデルの一部も展開します。 これはどこから入手しましたか？ また、ISO / OSIモデルの7つのレベルを覚えておいてください。レイヤー間の垂直相互作用に加えて、水平（論理）相互作用（プロトコル）もあります。 接続の異なる側では、トランスポートは論理的にトランスポートと相互作用し、モデルはモデルと、フレームワークとフレームワークと相互作用する必要があります（図を参照）。 さらに、垂直インタラクションでは抽象レベルが異なり、水平インタラクションでは同じレベルにあります。
したがって、Storage-Model-Application-Renderer-Template-Modelがあります。これは、もちろんSmartModelで短縮されており、アプローチの意味を反映しています。 しかし、これはすでにメタプログラミングの分野からのものであり、これについては別の記事で詳しく説明します。
筆者（これらのアイデアは長い間空を飛んでいます）も、これが情報システムのアーキテクチャに対する唯一かつ最も正しいアプローチであるという事実も主張しません。 完全に、私はこれがどこかで実装されたことをまだ見ていません。 これは、完成したプラットフォームの説明ではなく、アクションプランです。しかし、すでに多くのフラグメントを実装しており、すぐにオープンソースで公開します。
ご清聴ありがとうございました。