単体テストはMVCパターンの主な目的ですか？

最近のインタビューで、質問の1つは「なぜMVCを使用するのですか？」実世界のシステムの多くは、どれほど近いかと答えただけです！保守性、スケーラビリティなどに関しては利点があることを説明しました。しかし、彼らは納得できず、MVCは主に「簡単な単体テストを可能にする」ために使用されると言いました。

私は彼らのものが有効なポイントであることを知っていますが、（i）ユニットテストケースを書かないと決めたとしても、MVCはおそらく選択肢であるため、それが主な理由であるかどうか疑問ですMVCに従ってください。

質問は「ユニットテストはMVCパターンの主な目的ですか？」です。

編集：私は彼らがテスト駆動開発/ NUnitテストケースを書くことの容易さについて言及しているかもしれないと思います。これは、モデルのテストケースを作成できるためです（ビューがモデルの状態の変化を正確に反映している場合）。間違っている場合は修正してください。

モデル、ビュー、およびコントローラーはすべて別個の責任を負うため、主な目的は「懸念の分離」です。

元のゼロックスPARC論文の著者は次のように述べています。

MVCの本質的な目的は、人間のユーザーのメンタルモデルとコンピューターに存在するデジタルモデルとの間のギャップを埋めることです。

単体テストが主要な目的である場合、ビューを簡単に単体テストすることができます。ユニットテストプロジェクト/フレームワークの風景を見ると、それが主張に反していることが明らかになります。通常、統合テストと機能テストを使用してビューをテストします。

私の意見では、答えはしっかりした「いいえ」です。おそらく、これがこの特定の組織で観察された主な利点でしたが、私はそれを「主要な目的」とは呼びません。

MVCをある意味で実装するのはそれほど難しいことではなく、ユニットテストが非常に難しい（おそらく、私が初めてやった方法はほとんどテストできませんでした）。

一方、ほとんどのパターン（シングルトンのようなものを除く）は、ほとんどの場合デカップリングを促進するため、ユニットテストを促進すると言うことができますが、それは「主な目的」ですか？ほとんどない。

MVC（ほとんどの既知の設計パターンと同様）は、単体テストが知られるようになる前の段階でした。GoFの本は1994年に出版されました-そして、彼らは何十年も前（数十年ではないにしても）使用されてきたパターンのみを文書化していました。（そして、ユニットテストについては言及されていません。）ユニットテストについては、「パブリック」になった正確な時間を見つけることができません。 1999年に登場しました。

したがって、明らかに、ユニットテストはパターンの作成/文書化の主な目的ではありませんでしたが、パターンを適切に適用するとユニットテストが大幅に容易になると言っても過言ではありません。

ユニットテストの容易さは利点の1つですが、MVCを使用する際の利点のコレクションの一部であり、その理由を挙げてください。MVCを使用する主な理由は1つしかないと言うのは間違いです。問題の会社は、単体テストを容易にするためにMVCを選択しているように思われるため、それが主な理由であると考えています。個人的にMVCを使用する理由は、Webフォームと比較してシンプルであるため、設計および保守が容易になりますが、すべての個人/企業には、テクノロジーを使用する独自の理由があります。

ASP.NET MVCの世界では、ASP.NETの多くの改善がフレームワーク自体に含まれています。この設計パターンの主な目的は、ビジネスロジックをユーザーインターフェイスから分離して、メンテナンス性の向上、テスト容易性の向上、およびアプリケーションの構造のクリーン化に重点を置くことです。

ASP.NET MVCには、次の1つ以上が必要な場合に選択する最適なオプションとなる特定の機能があります。

• 生成されたHTMLに対する高度な制御：Webフォームとは異なり、ASP.NET MVCのビューは、ユーザーが指示したとおりにHTMLをレンダリングします。最近、この領域でWebフォームが改善されましたが、MVCの制御レベルはまだありません。

• 簡単なユニットテスト：ASP.NET MVCを使用すると、テスト駆動開発（TDD）などのテストパターンを簡単に追跡できます。Webフォームのイベントライフサイクルは複雑であるため、コントロールベースのフレームワークに加えて、MVDではTDDがはるかに簡単になります。

• 懸念の分離：これは、システムのすべての側面を互いに明確に分離することを指します。実装するパターンにより、MVCアプリケーションは個別の部分と緩やかにバインドされた部分（モデル、ビュー、コントローラー）に分割され、保守が容易になります。

その他の利点のいくつかは次のとおりです。

MVCパターン自体は、アプリケーションの機能をモデル、ビュー、コントローラーの3つのコア部分に明確に分離することにより、複雑さを管理しやすくします。

•ASP.NET MVC Webアプリケーションは、ビューステートまたはサーバーベースのフォームを使用しません。これにより、MVCフレームワークは、アプリケーションの動作を完全に制御したい開発者にとって理想的です。ビューステートは非常に大きくなる可能性があります。これは、低速ネットワークで実行されるスマートフォンなどのデバイスの問題です（すべての情報の送信は非常に遅くなる可能性があります）。Webフォームページでは、ページごとに1つしか持てません。これは非常に大きな制限です。MVCには、このような制限はありません。つまり、好きなだけ要素を持つことができます。

•ASP.NET MVCは、テスト駆動開発（TDD）のサポートを改善します。

•ASP.NET MVCは、大規模な開発者チームがサポートするWebアプリケーションや、HTMLを高度に制御する必要があるWebデザイナーに適しています。ASP.NET MVCリクエスト処理