iOSの顔質問：MVCとMVVMの違い

MVCとMVVMの違い

1. MVC

MVC

MVCの欠点

ヘビービューコントローラ
- M：対象のモデルに基づいて、通常は非常に簡単です。アップルのドキュメントは、モデルデータは、ビジネス・ロジックとデータの操作が含まれます。実際には、モデル層はどのような場合には、ビジネスロジック層モデルがコントローラにドラッグするべきではない、多くの場合、非常に薄いです。
- V：典型的には、ビューのビュー（ここで翻訳された対照食餌に係る部品）のUIKitコントロール設定または定義された符号化制御のUIKit。、そして、参照のみのコントローラIBActionイベントによって：（現実には、あなたが知っている！PS）ビューモデルを直接参照するべきではありませんが、なぜ聞かせコントローラーが知っている：（IBまたは手書きインタフェースPS）を構築する方法の表示。ビジネスロジックは明らかビューに含まれていない、ビューは、すべてのビジネスを持っていません。
- C：コントローラのコントローラ。配位モデルとビューの間のすべての相互作用：コントローラアプリは「グルー・コード」です。コントローラは、独自のビュー階層ビューを管理するだけでなく、ロードビューに対応して、多くの場合、モデル・ロジック・モデルのもいっぱい、表示されて消え、などなどを、私たちはビューに公開したくないビジネスロジックを公開したくありません。ネットワークデータ以降の処理を要求し、ローカルデータベース操作、ならびに方法と補助具の一部の特性は、大規模なビューコントローラの発生が増加しています。
ネットワーク・ロジック（どこの場所に）失われた
すべてのオブジェクトは、モデル、ビュー、またはコントローラのように分類することができます：MVCアップルを使用して定義されているので、言います。

あなたは、モデルでそれを試してみてくださいネットワーク要求を保持するので、もしネットワークがそのモデルのライフサイクルが長いよりも、物事が複雑になり、非同期呼び出しを使用する必要がありますので、内部のオブジェクトだけでなく、非常に難しいです。明らかに、曲のうち、より多くのようにのみコントローラーをそれを行うネットワーク要求を表示します。もしそうなら、これは大規模なビューコントローラの問題を悪化させています。もしそうなら、どこのネットワークホームの論理がありますか？

悪いテスト容易性

これらの構成要素のビューコントローラ混合ビュー処理ロジックとビジネス・ロジックユニットテストの分離が困難な課題となっているからです。

2. MVVM

方法は、良い解決策Massive View Controllerの問題には、特別な場所に配置された抽出されたロジック・コントローラを、示すことであり、この場所ですviewModel。MVVMは、それがビジネスロジックとUIコードの分離を容易にMVCの進化で、MVCを導出しました。これは、密結合形式仕様のビューとコントロールの性質、および新しいコンポーネントの導入です。次のようにそれらの間の構造的関係は以下のとおりです。

MVVM

2.1 MVVMの基本的な考え方

ではMVVM、中央、viewおよびview controller正式に一緒に、我々はコンポーネントとしてそれらを参照してください
viewそしてview controllerそれが直接参照することができないmodel（代わりに、ビューモデルを参照します、viewModel）
viewModel ユーザー入力の検証を配置することは論理的、論理ビューの表示、元のネットワークコードの要求や他の場所であります
使用しMVVMたコードの量のわずかな増加を、それは、コードの全体的な複雑さを軽減

2.2 MVVMノート

view参照viewModelではなく、その逆（すなわち、NOT IN viewModelの導入#import UIKit.h自体が配置されるべきではない、任意の参照ビューviewModel内）（PS：満たされなければならない基本的な要件）
viewModelリファレンスmodelではなく、その逆* MVVMの推奨
MVVMそれはあなたの現在の使用と互換性を持つことができるMVCアーキテクチャ。
MVVM あなたのテスタビリティアプリケーションを増やします。
MVVM結合機構を備えた最高の作品（PS：ReactiveCocoaあなたが値します）。
viewControllerビジネスロジックを伴わないようにしてくださいので、viewModelこれらのことを行います。
viewController 只是一个中间人，接收 view 的事件、调用 viewModel 的方法、响应 viewModel 的变化。
viewModel 绝对不能包含视图 view（UIKit.h），不然就跟 view 产生了耦合，不方便复用和测试。
viewModel之间可以有依赖。
viewModel避免过于臃肿，否则重蹈Controller的覆辙，变得难以维护。

2.3 MVVM 的优势

低耦合：View 可以独立于Model变化和修改，一个 viewModel 可以绑定到不同的 View 上
可重用性：可以把一些视图逻辑放在一个 viewModel里面，让很多 view 重用这段视图逻辑
独立开发：开发人员可以专注于业务逻辑和数据的开发 viewModel，设计人员可以专注于页面设计
可测试：通常界面是比较难于测试的，而 MVVM 模式可以针对 viewModel来进行测试

2.4 MVVM 的弊端

数据绑定使得Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
对于过大的项目，数据绑定和数据转化需要花费更多的内存（成本）。主要成本在于：
数组内容的转化成本较高：数组里面每项都要转化成Item对象，如果Item对象中还有类似数组，就很头疼。
转化之后的数据在大部分情况是不能直接被展示的，为了能够被展示，还需要第二次转化。
場合にのみ、非常に標準化され、これらのオブジェクトのプロトタイプでAPIが返すデータは、（ Item）には、再利用性の高いこと、または爆発のタイプを起こしやすい、メンテナンスコストを増やすことができます。
直接よりもオブジェクトのプロトタイプのデバッグのデータ内容を閲覧することでNSDictionary/NSArray直感的。
同じAPIのデータは、異なるビューを示しているときに必要な場所に、コードデータの変換を制御することは困難で、彼らが飛散することができます。

3.まとめ

MVCデザインパターンとは、少なくとも現在MVCデザインパターンはまだiOSの開発フレームワークの主流である、合理的な存在である、末期、不治のアーキテクチャではありません。欠点のための記事が、我々はまだので、軽量を作成し、回避し、解決する可能性のある方法がたくさんありますViewController。
MVVMあるMVCアップグレードされたバージョンは、現在のMVCアーキテクチャと完全に互換性があり、MVVMにある程度のUIコードとビジネス・ロジックに、分離を低減するために昇格がViewControllerなく、肥大化の程度ViewとViewModel結合との間のデータは、MVVMを使用する複雑かつ困難になることができますデータ我々は2つのバインディングの間のより良い管理することができない場合、それはまた、コードのロジックの問題を維持することは困難で、コントローラーのコードが複雑すぎる原因となります。
軽量をViewControllerベースにMVCし、MVVM業務モデルのコードとビルドの分離。MVCとMVVMは長所と短所が、彼らがもたらす恩恵の前で言及する価値欠点があります。彼らの低カップリング、カプセル化、テスト容易性、保守性、および多くの人々は、効率を大幅に向上させopenメソッドを促進するために一緒に働きます。
同時に、我々は抱擁変更心と合理的な分析の態度を維持する必要があります。新しい技術ではなく、盲従、また保守の顔には、すべての決定は、技術の変化に対応するためには、慎重な分析に基づくべきです。

もっと：iOSの顔質問集