MVCパターンは長い間市場に出回っていますが、多くの人がさまざまな方法で使用しています。
問題は何ですか？ 実際、多くの開発者はコードを非常に複雑にし、それを維持し、開発するのに費用がかかるか、グローバルなリファクタリングを行う必要があり、これはビジネスにとって非常に不利です。
主な目標は、プロジェクトを予定通りに完了し、計画された予算に投資することでプロジェクトをさらに発展させることです。
コードの品質に関する重要な基準の1つは、その単純さです。 しかし、シンプルさを測定する方法は？ 1つのオプションは、システム要素の数を計算することです。 要素が少ないほど、システムは簡単になります。
最適化できない限り、ビジネスロジックはプログラマではなくビジネスに依存するため、ビジネスロジックの実行回数を減らすことはできません。 基準は次のようになります-コードの数はビジネスロジックではありません。 開発の経験から、MVCを次のように分割すると非常に便利であることがわかりました。
コアコンポーネント
サーバー環境のニーズ
ルーティング
共通ライブラリ
M（コントローラーは異なるオブジェクトと接続できます）：
ビジネスロジックの第2層
取得、設定、データ処理
HMVC Contollers
アダプター（他のサービスと簡単に作業するため）
V =テンプレート、ヘッド、フッタースクリプト、パーツ
C =簡単なコードとビジネスロジックの最初の層
+ L =ライブラリ（高度なコンポーネントとサードパーティコンポーネント用）
多くの人はモデルがデータを操作していると理解しています。これは、データベースまたは内部サービス全体からデータを受け取るか、ビューに挿入するMVCコンポーネントを組み立てることです。 それらは強く接続されておらず、コードを簡単に拡張できることが望ましい。
Web開発のビューには、多くの場合、ヘッドヘッダーとスクリプトが含まれています。これらは外観ではなく、別の意味を持っています。 それらを別々のファイルに転送することをお勧めします。 また、プロジェクトのスケーリングを容易にするために、ビューを簡単にパーツに分割する必要があります
コントローラーは、束全体の主要な要素です。 顧客のリクエストに対する反応を配信します。 多くの場合、この配布は最初の段階でRotutingによって実行され、その後コントローラーメソッドでのみ必要なデータがすべて収集され、ビューに配置されます。
このアーキテクチャは最適であると考えています。 各方向はOOPを使用し、抽象クラスを継承し、より複雑になる可能性がありますが、コードを簡単に拡張し、集合作業に便利にするために、境界を観察することが重要です。
多くのフレームワークがこのアーキテクチャをサポートしており、多くのきちんとした開発者がこのようなプログラムを構築しています。
上記の要素がコード内で混乱している場合、できるだけ早くリファクタリングし、その後の開発プロセスを大幅に加速することをお勧めします。
ご清聴ありがとうございました。
他の優れたアーキテクチャのオプションを知っている人がいれば、コメントにあなたの意見を書いてください、ありがとう。
MVCとWebアプリケーションアーキテクチャについて話す
All Articles