MVC とは何ですか?また、その利点は何ですか?[閉まっている]
https://stackoverflow.com/questions/26685
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
見つけました mvp と mvc とは何ですか、またその違いは何ですか しかし、それはこの質問に対する本当の答えにはなりませんでした。
最近 MVC を使い始めました。これは、私自身と仕事のパートナーが使用するフレームワークの一部だからです。簡単そうに見えてプロセスと表示が分離されているという理由でこれを選択しましたが、これ以外に私たちが知らない、見逃している可能性のある利点はありますか?
長所
- 表示と処理を分離
短所
- 今のところ何もありません
解決
MVC は次のものを分離したものです。 メートルオーデル、 vええと c管理者 — それ以上でもそれ以下でもありません。それは単なるパラダイムにすぎません。これは、クラスを設計するときに頭の片隅に置いておくべき理想です。3 つのカテゴリのコードを 1 つのクラスに混在させないでください。
たとえば、テーブルグリッドの場合、 ビュー 表示されたデータは明らかに表示されるべきであり、データをどこから取得するか、またはそのネイティブ構造 ( モデル） のようなものです。同様に、列を合計する関数がある場合がありますが、実際の合計は コントローラ.
「ファイルの保存」ダイアログ (ビュー) は、ユーザーが選択したパスを最終的に コントローラ, 、次に、 モデル データを保存し、実際の保存を行います。
この責任の分離により、将来的には柔軟性が得られます。たとえば、ビューは基礎となるモデルを考慮しないため、複数のファイル形式をサポートする方が簡単です。それぞれにモデルのサブクラスを追加するだけです。
他のヒント
懸念事項を分離することが重要です。
これらのコンポーネントを分解できるため、コードの再利用や独立したテストが容易になります。実際に MVC が何なのかを知らない場合は、「モデル」が何であるか (ビジネス オブジェクト/データセット/データテーブルであるか、それとも基礎となるサービスを表すか) についてはまだ議論があるため、人々の意見を理解しようとする際には注意してください。層）。
私は自分自身を MVC と呼ぶあらゆる種類の実装を見てきましたが、正確には MVC ではなく、次のコメントのように ジェフの記事 show MVC は議論の余地のある点であり、開発者が完全に同意するとは思えません。
さまざまな MVC タイプをすべてまとめたものが利用可能です ここ.
MVC パターンを使用するもう 1 つの利点は、他のパターンへの扉が開かれることだと思います。 アプローチ MVP/Presenter first やその他の多くの MV* パターンなどのデザインに適用されます。
設計「コンポーネント」のこの基本的な分離がなければ、これらの技術の導入ははるかに困難になります。
コードをさらにインターフェイスベースにするのに役立つと思います。個々のプロジェクト内だけでなく、共通の「ビュー」の開発をほぼ始めることができます。これは、アプリケーションで使用されるより多くの「グラント」コードをテンプレート化できることを意味します。たとえば、非常に抽象的な「データ ビュー」は、単純に大量のデータを取得し、それを共通のグリッド レイアウトにスローします。
編集：
もし私が正確に覚えていれば、 これは MV* パターンに関する非常に優れたポッドキャストです （ちょっと前に聞きました！）
私が考えられる欠点の 1 つは、ビュー内のデータ (たとえば、ボーンの位置などのゲーム アニメーション データ) に非常に高速にアクセスする必要がある場合です。この場合、分離レイヤーを維持するのは非常に非効率です。
それ以外の場合、グラフィックス駆動型よりもデータ駆動型の他のほとんどのアプリケーションにとって、これは UI を駆動する論理的な方法のように思えます。
stackoverflow ポッドキャストをフォローすると、Jeff (と Geoff?) がその素晴らしさについて語るのを聞くことができます。 http://blog.stackoverflow.com/2008/08/podcast-17/. 。ただし、これらの個別のレイヤーを使用すると、将来的には作業が容易になり、現在は難しくなるということを意味することを忘れないでください。そしてレイヤー できる 物事を遅くする。そして、それらは必要ないかもしれません。しかし、だからといって、それが何であるかを学ぶのをやめさせないでください。大規模で堅牢で寿命の長いシステムを構築する場合、それは非常に貴重です。
コントローラーによって制御されるモデルとビューを分離します。モデルに関する限り、モデルはOOアーキテクチャに従う必要があります。将来の拡張機能、およびコードベースのその他のメンテナンスは非常に簡単で、コードベースは再利用可能です。
同じモデルは任意の数のビューを持つことができます。たとえば、同じ情報を異なるグラフィカル ビューとして表示できます。同じビューに異なる数のモデルを含めることができます。たとえば、異なる詳細を単一のグラフ、たとえば棒グラフとして表示できます。これが View と Model の両方の再利用性です。
ビューの機能強化や、ビューを構築するための新しいテクノロジーのその他のサポートを簡単に実装できます。
ビューに取り組んでいる人は、基礎となるモデルのコード ベースとそのアーキテクチャについて知る必要はありません。モデルの場合はその逆です。
MVC は、リーン Web アプリ開発のコンテキストにおいて、開発者がクライアント リクエストを受信して処理するメソッド (ビュー) から HTML マークアップをアプリのプレゼンテーション層 (ビュー) に簡単に保持できるようにする一般的なデザイン パターンです。コントローラー) とビュー内で返されるデータ表現 (モデル)。すべては関心事の分離、つまり 1 つの機能目的を果たすコードを維持することです (例:クライアントリクエストの処理など）を完全に異なる機能目的を果たすコードから隔離します（例:データを表す)。
これは、Web サイトの構築に 5 分以上費やした人であれば、HTML マークアップ、JavaScript、CSS を別のファイルに保存する必要性を理解できるのと同じ原理です。すべてのコードを 1 つのファイルにダンプすると、後で事実上編集できないスパゲッティが作成されます。
考えられる「短所」を尋ねたので、次のようになります。 私はソフトウェア アーキテクチャ設計の専門家ではありませんが、MVC での開発経験に基づいて、厳格で飾り気のない MVC 設計パターンに従うことが、1) 軽量の Web アプリ、または 2) に最も役立つことを指摘することも重要だと思います。 ) より大規模なエンタープライズ アプリの UI レイヤーとして。MVC には、ビジネス ロジック、ドメイン モデル、またはアプリのデータ アクセス層にあるものについての明示的な定義が含まれていないため、この仕様があまり話題になっていないことに驚きました。私が ASP.NET MVC で開発を始めたとき (つまり、他のソフトウェア アーキテクチャが存在することを知る前に)、非常に肥大化したコントローラーや、ビジネス ロジックがぎっしり詰まったビュー モデルができてしまったでしょう。もし私がエンタープライズ アプリケーションに取り組んでいたら、私のアーキテクチャに不慣れな他の開発者にとっては困難になっていたでしょう。変更するコード (すなわち、スパゲッティをもっと）。
ここでは触れていない MVC の主な利点の 1 つは、MVC が SEO を可能にする RESTful URL を提供することです。コントローラーとアクションに賢明な名前を付けると、検索エンジンがサイトの URL だけを参照する場合でも、サイトを見つけやすくなります。たとえば、車の販売 Web サイトと、入手可能なランボルギーニ ヴェネーノ車を表示するページがあるとします。 www.MyCarSale.com/product/6548 選択できるページを参照してください www.MyCarSale.com/SportCar/Lamborghini-Veneno SEO目的のURLです。
MVC アーキテクチャの主な利点は、コードの再利用性、コードの保守と保守の容易さのためにモデル、ビュー、コントローラーでプロジェクトのレイヤーを区別することです。最も良いのは、開発者がプロジェクトのメンテナンスの合間にコードを追加することに満足できることです。
ここでさらにいくつかのポイントを確認できます MVC アーキテクチャの主な利点.
![mvc アーキテクチャ][1]
モデル ビュー コントローラー (MVC) は、ユーザー インターフェイスを実装するためのソフトウェア アーキテクチャ パターンです。これは、情報の内部表現を、情報がユーザーに提示またはユーザーから受け入れられる方法から分離するために、特定のソフトウェア アプリケーションを相互に接続された 3 つの部分に分割します。
