MVCの欠点は何ですか？
数年前に実際にコードの整理を始めて以来、MVC/MV *を使用しています。私はそれを長い間使用しているので、コードを構造化する他の方法を考えることすらできません。インターンになった後のすべての仕事はMVCベースでした。
私の質問は、MVCの欠点は何ですか？ MVCはプロジェクトの悪い選択であり、（もっと）正しい選択はどのような場合でしょうか？ MVCの代替案を調べると、ほとんどすべての結果が異なるタイプのMVCです。
これが閉じられないようにスコープを絞り込むには、Webアプリケーションについて考えてみましょう。私はさまざまなプロジェクトのバックエンドとフロントエンドに取り組んでいるので、フロントエンドまたはバックエンドだけとは言えません。
MVCはUI関連のパターンです。複雑なアプリケーションを構築している場合、MVCトリプレットからUIに関係のないすべてのものを他のクラス、サブシステム、またはレイヤーに取り込む必要があります。
それは私の最大の間違いでした。私はその単純なルールを理解するのに長い時間を費やしました：
- MVCパターンをアプリケーション全体に分散させないでください。
- UI関連のもののみに制限します。
作成するコードが論理的に正しい場所にあるかどうか、つまり、コードが配置するクラスの責任領域に論理的に適合するかどうかを常に確認してください。そうでない場合-理解したらすぐにコードを移動してください。
MVCの代替案（Model-View-Presenter、Model-View-ViewModel）と呼ばれるすべてのパターンは、一般的なMVCコンセプトを実装するための単なる方法です。
私の意見では、MVCには純粋なものと不純なものの2種類があります（より優れたWordがないため）。
純粋なMVCは、スモールトークに導入されたものです。
これは、パーソナルコンピューティング/デスクトップアプリケーション用です。ご覧のように、モデルはモデルに加えられた更新/変更をビューに通知します。 （純粋でない）MVCではそうではありません。
Webアプリケーションで推奨されているもう1つの（純粋でない）MVCは、上記の従来のMVCではなく、PAC（ Presentation-abstraction-control ）パターンです。これは、コードの編成と懸念の分離の詳細です。
- Model：保存されたデータの抽象化
- Control：通常、ビジネスロジックレイヤーと呼ばれるものと、対応するビジネスロジック（別名コントローラー）にHTTPリクエストをルーティングするアプリケーションの一部）
- View：ほとんどの場合、モデルからのデータをフォーマットしてクライアントに返すテンプレートを表示します。モデルは更新をビューに送信しないでください。また、ビューはモデルからの更新をサブスクライブしません。それは悪夢のようなものになるでしょう。したがって、真のMVCよりもPACに似ています。
ここで、Webアプリケーションの通常の構造を示します。
- フロントエンド：Backbone.jsなどのフレームワークを使用するクライアントのMVC、これは本質的に「真の」MVCフォームです。
- バックエンド：繰り返しますが、コードの整理と懸念の分離のための（純粋でない）MVC/PACがあります
- グローバルWebアプリ（Webアプリケーション全体）：JSONデータのみを返すRESTfulバックエンドがある場合、バックエンド全体は次のように認識されます。 amodel：ビューとコントローラーが本質的に存在するフロントエンドクライアントアプリケーション。
では、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だけではありませんOOP自体は、物事を単位に分解するための素晴らしい概念です。
MVC/MV *は、UI関連の開発を処理する場合に非常に役立ちますが、その下には、ファクトリー、シングルトン、ファサードなど、より多くのパターンがある場合があります。大きなプロジェクトの大部分は、さまざまな側面を処理する複数のレイヤーで構成されますが、UIは必須ではない場合がありますある場合。 MVCがよく表示される場合があります。これは、多くのプロジェクトにUI要素があるためです。
したがって、MVCの欠点について話しながら、それは本当にあなたがしているプロジェクトに依存します-それはUIを持っていますか？優れたスケーラビリティ/拡張性が必要ですか？ UIと背後のシステムの間に多くの相互作用がありますか？たとえば、単純な情報Webページは、将来的にインタラクティブなページに拡張する予定がない限り、MVCをまったく必要としません。
mVC（またはより一般的な-デザインパターン）を評価するには、コンテキストを与え、複雑さ、スケーラビリティ、テスト可能性、メンテナンス、時間制約などについて考えます。