mvp と mvc とは何か、そしてその違いは何かを見つけましたが、この質問には実際には答えませんでした。
私は最近 MVC を使い始めました。これは、私自身と私の仕事のパートナーが使用するフレームワークの一部であるためです。簡単に見え、プロセスと表示が分離されているため、これを選択しました。これ以外に、私たちが知らない、見逃している可能性のある利点はありますか?
長所
- 表示と処理を分離
短所
- 今のところなし
mvp と mvc とは何か、そしてその違いは何かを見つけましたが、この質問には実際には答えませんでした。
私は最近 MVC を使い始めました。これは、私自身と私の仕事のパートナーが使用するフレームワークの一部であるためです。簡単に見え、プロセスと表示が分離されているため、これを選択しました。これ以外に、私たちが知らない、見逃している可能性のある利点はありますか?
長所
短所
MVCは、モデル、ビュー、およびコントローラーの分離であり、それ以上でもそれ以下でもありません。これは単なるパラダイムです。クラスを設計するときに心の奥底にあるべき理想。3つのカテゴリのコードを1つのクラスに混在させないでください。
たとえば、テーブルグリッドビューは、表示されたデータを明らかに表示する必要がありますが、データを取得する場所や、そのネイティブ構造(モデル)がどのようなものかに関するコードを含めるべきではありません。同様に、列を合計する機能がある場合でも、実際の合計はコントローラーで行われることになっています。
「ファイルの保存」ダイアログ(ビュー)は、ユーザーが選択したパスを最終的にコントローラーに渡します。コントローラーは、モデルにデータを要求し、実際の保存を行います。
この責任の分離により、将来の柔軟性が可能になります。たとえば、ビューは基になるモデルを考慮しないため、複数のファイル形式をサポートする方が簡単です。それぞれにモデルサブクラスを追加するだけです。
関心の分離は重要です。
これらのコンポーネントを分解できると、コードの再利用と個別のテストが容易になります。MVC が何であるかを実際に知らない場合は、人々の意見を理解しようとすることに注意してください。「モデル」とは何か (それがビジネス オブジェクト/データセット/データテーブルであるか、それとも基礎となるサービスを表しているか) についてまだいくつかの論争があるためです。層)。
自分自身を MVC と呼んでいるが正確ではないあらゆる種類の実装を見てきました。Jeff の記事のコメントが示しているように、MVC は開発者が完全に同意するとは思えない論争の的となる点です。
さまざまな MVC タイプのすべてをまとめたものは、こちらで入手できます。
ジェフはそれについての投稿を持っています、さもなければ私はアップルのウェブサイトで、Cocoaチュートリアル(例えばこれ)でいくつかの有用な文書を見つけました。
MVC パターンを使用するもう 1 つの利点は、MVP/Presenter ファーストや他の多くの MV* パターンなど、設計に対する他のアプローチへの扉が開かれることだと思います。
この基本的な設計「コンポーネント」の分離がなければ、これらの手法の採用ははるかに困難になります。
コードをさらにインターフェースベースにするのに役立つと思います。個々のプロジェクト内だけでなく、共通の「ビュー」の開発をほぼ開始できます。つまり、アプリケーションで使用される「単調な」コードをより多くテンプレート化できます。 . たとえば、単純に一連のデータを取得して共通のグリッド レイアウトにスローする、非常に抽象的な「データ ビュー」です。
私の記憶が正しければ、これは MV* パターンに関する非常に優れたポッドキャストです(少し前に聞いたことがあります!)。
MVC は、無駄のない Web アプリ開発のコンテキストで、開発者が HTML マークアップをアプリのプレゼンテーション レイヤー (ビュー) に保持し、クライアント要求を受け取って処理するメソッド (コントローラー) と、ビュー内で返されるデータ表現 (モデル) です。つまり、1 つの機能目的 (クライアント要求の処理など) を提供するコードを、まったく異なる機能目的 (データの表現など) を提供するコードから隔離しておくことです。
HTML マークアップ、JavaScript、および CSS を別々のファイルに保存する必要性を、Web サイトの構築に 5 分以上費やした人なら誰でも理解できるのと同じ原則です。すべてのコードを 1 つのファイルにダンプすると、後で実質的に編集できないスパゲッティになってしまいます。
あなたが可能な「短所」を求めたので:私はソフトウェア アーキテクチャ設計の権威ではありませんが、MVC での開発経験に基づいて、厳密で飾り気のない MVC 設計パターンに従うことは、1) 軽量 Web アプリ、または 2 ) を大規模なエンタープライズ アプリの UI レイヤーとして使用します。MVC にはビジネス ロジック、ドメイン モデル、または実際にはアプリのデータ アクセス レイヤーにあるものに対する明示的な定義が含まれていないため、この仕様がこれ以上語られていないことに驚きました。私が ASP.NET MVC で開発を始めたとき (つまり、他のソフトウェア アーキテクチャが存在することさえ知らなかったとき) は、非常に肥大化したコントローラーになったり、ビジネス ロジックでぎっしり詰まったモデルを表示することさえありました。私のコードに慣れていない他の開発者が変更するのが難しくなりました(つまり、スパゲッティが増えました)。
コントローラーによって制御されるモデルとビューを分離します。モデルに関する限り、モデルは OO アーキテクチャに従う必要があり、コード ベースの将来の拡張やその他のメンテナンスは非常に簡単で、コード ベースは再利用可能でなければなりません。
同じモデルに任意の数のビューを含めることができます。たとえば、同じ情報を異なるグラフィカル ビューとして表示できます。同じビューに異なるモデル数を表示できます。たとえば、異なる詳細を棒グラフなどの 1 つのグラフとして表示できます。これがビューとモデルの両方の再利用性です。
ビューの拡張や、ビューを構築するための新しいテクノロジのその他のサポートは、簡単に実装できます。
ビューに取り組んでいる Guy は、モデルの基礎となるコード ベースとそのアーキテクチャについて知る必要はありません。モデルについてはその逆です。
stackoverflow ポッドキャストをフォローすると、Jeff (および Geoff?) がその素晴らしさについて話しているのを聞くことができます。 https://blog.stackoverflow.com/2008/08/podcast-17/ . ただし、これらの個別のレイヤーを使用すると、将来は簡単になり、現在は難しくなることを忘れないでください。また、レイヤーは物事を遅くする可能性があります。そして、あなたはそれらを必要としないかもしれません. しかし、それが何であるかを学ぶことをやめさせないでください。大規模で堅牢で長寿命のシステムを構築する場合、それは非常に貴重です。
私が考えることができる 1 つの短所は、ビュー内のデータ (たとえば、ボーンの位置などのゲーム アニメーション データ) に非常に高速にアクセスする必要がある場合です。この場合、分離のレイヤーを保持することは非常に非効率的です。
それ以外の場合、グラフィックス駆動よりもデータ駆動型の他のほとんどのアプリケーションでは、UI を駆動する論理的な方法のように思えます。
ここで触れていない MVC の主な利点の 1 つは、MVC が SEO を可能にする RESTful URL を提供することです。コントローラーとアクションに適切な名前を付けると、検索エンジンがサイトの URL のみを参照するだけでサイトを見つけやすくなります。たとえば、自動車販売の Web サイトと利用可能な Lamborghini Veneno 車を表示するページがあるとします。そのページを参照するwww.MyCarSale.com/product/6548の代わりに、www.MyCarSale.com/ SportCar /Lamborghini-Veneno のURL を選択できます。 SEOの目的。
MVC アーキテクチャの主な利点は、プロジェクトのレイヤーをモデル、ビュー、およびコントローラーで区別して、コードの再利用性を高め、コードの保守と保守を容易にすることです。最良のことは、開発者がプロジェクトのメンテナンスの間にコードを追加することに満足していることです。
ここでは、MVC アーキテクチャの主な利点に関するその他のポイントを確認できます。
![mvc アーキテクチャ][1]
モデル ビュー コントローラー (MVC) は、ユーザー インターフェイスを実装するためのソフトウェア アーキテクチャ パターンです。これは、特定のソフトウェア アプリケーションを相互接続された 3 つの部分に分割し、情報の内部表現を、ユーザーに情報を提示したりユーザーから受け取ったりする方法から分離します。