最近、Model-View-Controller（MVC、技術的な観点からはCMVの方が正しい）の概念に従って実装された最初のプロジェクトを完了しました。 この記事では、読者にこの概念に対する私の個人的な印象を知ってもらうように勧めています。
ご注意
記事に書かれていることはすべて私の個人的な意見です。 読者として、あなたは彼に同意する必要はありません。この記事の目的は、共通の概念に関する別の意見を読者に知らせることです。
MVCへの道
少し前に、ブログを作ることにしました。 しばらくWordPressをいじくり回していたので、 「魚はいない」という結論に達しました（そして今日、サイトへのリクエストの統計を見ると、WordPressを放棄することが正しい判断だったと思います）。 一般に、外部要因（私の知識、必要な開発時間、追加のメンテナンスコストなど）の全体を分析した後、私はすべてをゼロから開発することにしました。 そして、プログラムの編成のメカニズムを選択するために手が解かれたので、広く宣伝されているMVCコンセプトを「自分自身で」試してみることにしました（以前のプロジェクトではモジュール方式を使用しました）。MVCの私の理解
私が見つけた技術文書は、かなり難解な定式化を使用しているため（「モデルと表現を使用して必要な反応を実装する」など）、MVCの概念についての理解を書く必要があります（誤解がないように）。したがって、MVCの概念によれば、アプリケーションは3つの基本的な論理部分で構成される必要があります：コントローラー（コントローラー）、モデル（モデル）、ビュー（ビュー/表示）。 コントローラーブロック-ユーザーアクション（このコンテキストでは、ユーザーは必ずしも人ではない）をモデルの入力パラメーターに変換し、制御をモデルに転送します。 ブロックモデル-プログラムのすべてのロジックを実装し、表示用のデータを準備します。 ブロックビュー-プログラムの結果を視覚化します。 各ユーザーアクションは、常にコントローラー->モデル->ビューチェーンを開始します。
各ブロックの機能について、コントローラーについて詳しく説明します。
- 環境変数（POST / GET変数、コマンドラインパラメーター、URLパラメーターなど）を読み込みます。
- 環境変数の一次処理を実行します（変数のタイプ、それらの存在、デフォルト値の設定などを確認します）。
- 緊急事態を監視するメカニズムを実装します。
- ロギングメカニズムを実装します（認証ではなく、ロギング）。
モデル：
- 着信パラメーター（有効な値、範囲など）の最終検証を実行します。
- データストレージシステム（データベース、ファイル、SOAPなど）との対話を実装します。
- プログラムのロジックを実装します。
- 視覚化のためにデータを準備します。
表示：
- プログラムの結果を視覚化するメカニズムを編成します。
現時点では、プロジェクトは「開発と実装」段階から「保守と拡張」段階に移行しています。この段階では、MVCコンセプトの以下の利点と欠点に注目したいと思います（客観的で純粋に個人的な観察のふりをしません）。
MVCコンセプトの欠点
1.より多くのリソースを使用する必要性。 困難なのは、3つの基本ブロックすべてが完全に独立しており、データ転送を通じて排他的に相互作用するためです。 コントローラーは、変数の可能なすべての組み合わせを常に読み込み（必要に応じて作成し）、モデルに渡します。 次に、モデルは視覚化のためにすべてのデータをロードし、それをビューに渡す必要があります。 たとえば、モジュールアプローチでは、モジュールは環境変数を直接処理し、メモリの別のセクションにロードせずにデータを視覚化できます。2.プログラムをモジュールに分割するメカニズムは複雑です。 MVCの概念では、3つのブロック（モデル、ビュー、コントローラー）の存在が厳密に記述されています。 したがって、各機能モジュールは3つのブロックで構成する必要があり、そのため、プログラムの機能モジュールのアーキテクチャがやや複雑になります。
3.機能を拡張するプロセスは複雑です。 問題は上記と非常に似ています。 機能モジュールを作成して、プログラムの1か所に接続するだけでは十分ではありません。 各機能モジュールは3つの部分で構成され、これらの各部分は対応するユニットに接続されている必要があります。
MVCコンセプトの利点
1.統一されたシステムコンセプト。 MVCの間違いない利点は、統一されたグローバルアプリケーションアーキテクチャです。 複雑なシステムであっても、開発者（システムを開発した人と新しく参加した人の両方）は、ソフトウェアブロック内を簡単に移動できます。 たとえば、データ処理ロジックでエラーが発生した場合、開発者はプログラムの2ブロック（コントローラーとビュー）を直ちに破棄し、3番目（モデル）の調査に従事します。 問題のローカライズがどれほど単純化されているかにしばしば驚かされました。2.アプリケーションのデバッグメカニズムが簡素化されます。 視覚化メカニズム全体が1つのプログラムユニットに集約されるようになったため、グラフィック要素のオプション出力のメカニズムが簡素化されました。 このステートメントが従来のアプリケーションのプログラミングにどのように適用できるかを評価することはできませんが、Webプログラミングでは、このアーキテクチャ機能は明確なプラスになりました。
結論
MVCコンセプトを使用した全体的な印象は好意的でした。 私の注意を引いたこれらの困難は、より心理的です（常にこのようでしたが、現在は異なっています）。 同時に、通常のアプリケーション（Windowsなど）の開発にMVCの概念をどの程度適用できるかという疑問は私にとって未解決のままでした。 当たり前のことですが、最適であるという事実ではありません。さて、最も重要な質問：次のプロジェクトでMVCコンセプトを使用しますか？ 回答：そう思います。