MVCの衰退とは何ですか？[閉まっている]

数年前に実際にコードを整理し始めて以来、MVC / MV *を使用しています。私はそれを長い間使ってきたので、コードを構造化する他の方法を考えることすらできず、インターンになってからのすべての仕事はMVCベースでした。

私の質問は、MVCの没落は何ですか？どのような場合にMVCはプロジェクトにとって悪い選択であり、（より）正しい選択は何ですか？MVCの代替案を調べると、ほとんどすべての結果は異なるタイプのMVCにすぎません。

これが閉じられないように範囲を絞り込むには、Webアプリケーションの場合を考えてみましょう。私はさまざまなプロジェクトのバックエンドとフロントエンドで作業しているので、フロントエンドやバックエンドだけとは言えません。

常に覚えておく必要があります-MVCはUI関連のパターンです。複雑なアプリケーションを構築している場合は、MVCトリプレットから他のクラス、サブシステム、またはレイヤーに、UIに関連しないすべてのものを取得する必要があります。

それは私の最大の間違いでした。その単純なルールを理解するのに長い時間を費やしました。

• MVCパターンをアプリケーション全体に広げないでください。
• UI関連のもののみに制限します。

記述するコードが論理的に正しい場所にあるかどうかを常に確認してください。つまり、配置するクラスの責任範囲に論理的に収まることを意味します。

MVC-alternatives（Model-View-Presenter、Model-View-ViewModel）と呼ぶすべてのパターンは、一般的なMVCコンセプトを実装する方法にすぎません。

私の意見では、純粋なものと不純なものの2種類のMVCがあります（より良い単語がないためです）。

純粋なMVCは、スモールトークに導入されたものです。

これは、パーソナルコンピューティング/デスクトップアプリケーション向けです。ご覧のとおり、モデルはビューに対して行われた更新/変更を通知します。（不純な）MVCではそうではありません。

Webアプリケーション向けに宣伝されているもう1つの（不純な）MVC は、上記の古典的なMVCではなく、PAC（Presentation-abstraction-control）パターンです。それは、より多くのコード編成と懸念の分離です。

• モデル：保存データの抽象化
• コントロール：通常、ビジネスロジック層と呼ばれるもの、および対応するビジネスロジック（別名コントローラー）へのHTTPリクエストのルーティングを担当するアプリケーションの一部
• 表示：モデルからのデータをフォーマットしてクライアントに返すテンプレートを主に表示します。モデルがビューに更新を送信することはありません。また、モデルからの更新をビューがサブスクライブすることもありません。それは悪夢と結びついているでしょう。したがって、真のMVCよりもPACに似ています。

ここで、Webアプリケーションの通常の構造を次に示します。

1. フロントエンド：Backbone.jsなどのフレームワークを使用するクライアント上のMVC。これは本質的に「真の」MVCフォームです。
2. バックエンド：繰り返しますが、コードの編成と懸念の分離のための（不純な）MVC / PACがあります
3. グローバルWebアプリ（Webアプリケーション全体）：JSONデータのみを返すRESTfulバックエンドがある場合、バックエンド全体が、ViewとControllerが本質的に存在するフロントエンドクライアントアプリケーションのモデルとして認識されます。

それでは、MVCの欠点は何ですか？まあ、パターンは時の試練に耐えてきたので、少し「複雑」であること以外はそれほど重要なものは多くありません。ご覧のとおり、MVCは複合パターンです-戦略/オブザーバーパターンを実装し、すべてが高度なパターンを形成するように配置されています。

どこでも使用すべきですか？そうでないかもしれない。非常に複雑なWebアプリケーションは、複数のレイヤーに分割される可能性があります！ビュー/ビジネスロジック/データレイヤーだけでは済まない場合があります。包括的なフレームワーク/組織は、依然としてMVCに似ていますが、巨視的なレベルに限られます。

以下は、MVCだけが悪い選択の例です。大銀行向けに航空交通管制システムまたはローン/住宅ローン処理アプリケーションを設計してみてください。MVCだけが悪い選択です。必然的に、イベントバス/メッセージキューと、個々のレイヤー内にMVCを備えたマルチレイヤーアーキテクチャと、コードベースをより適切に整理するための包括的なMVC / PAC設計が必要になります。

多くの人がデザインパターンで犯す間違いは、1つの場所でそれが美しく機能するのを見て、それをどこにでも適用しようとすることです。

しばらくの間1つの場所で作業していた場合、その時点で流行していたテクノロジー/デザインパターン/プラクティス、たとえばシングルトン/依存性インジェクション/ TDDなどを確認することで、ほとんどコードの一部を作成できます。

どこで使用しないのか。まあ、MVCトリプレットの1つの要素が当てはまらないところはどこでも。コンソールアプリケーションは、インターフェイスをまったく実装しない場合があります。ユーティリティプログラムにはモデルがない場合があります。そして、おそらく、モデルもビューもない場合、コントローラーは必要ありません。

問題がコンセプトにあることはめったにありません-実装にあります。パラダイムがどれほど優れていても、それが手元の問題に適しているかどうかを時間をかけて見てください。

MVCは、開発プラットフォームに不可欠ではないパラダイムと同様に、複雑さが増します。欠点は、分離すべきではないクラスを分離してしまう可能性があり、それらのクラスがどれほど緊密に結合されているかの明確性を低下させることです。（または、些細なプロジェクトの場合は、コードを難読化します。）

最初の問題の代替案は、そのようなコードを独立したサブプロジェクトに分離することです。2番目の選択肢は、クラスまたはファイルモデルのいずれかで、分離されていないコードです。

MVC / MV *の適用に関する私の理解は、懸念の分離（SoC）の原則に従っています-プログラム/コードを個別のセクション/ピースに分離し、各セクションが個別の懸念に対処できるようにします（参照：http : //en.wikipedia.org / wiki / Separation_of_concerns）

懸念事項を分離する場合、多くの利点があります。1つは別の人に影響を与えず、開発者は残りの部分などに影響を与えずにユニットで作業できます。その他... SoCに続くパターンはMVCだけではありません。物事をユニットに分割する素晴らしいコンセプトです。

MVC / MV *はUI関連の開発を処理する場合に非常に役立ちますが、その下にはさらに多くのパターン（ファクトリー、シングルトン、ファサードなど）がある場合があります。ある場合。多くのプロジェクトにUI要素が含まれているため、MVCがよく表示されます。

したがって、MVCの欠点について話している間、それは本当にあなたがやっているプロジェクトに依存します-それはUIを持っていますか？優れた拡張性/拡張性が必要ですか？UIと背後のシステムの間に多くの相互作用がありますか？たとえば、単純な情報Webページは、将来優れたインタラクティブページに拡張する予定がない限り、MVCをまったく必要としません。

そのため、MVC（またはより一般的な-デザインパターン）を評価するために、コンテキストを与え、複雑さ、スケーラビリティ、テスト可能性、保守、時間の制約などについて考えます。