iOSのScapegoatまたはMVC

過去数年にわたって、私は多くのプロジェクト、開発者、およびiOSコミュニティで起こっているすべてではないにしても多くの原因でModel-ViewControllerアーキテクチャを非難する記事に出会いました。



今日、私はいくつかの代替的な見解とアプローチに加え、MVCとプロジェクト管理全般を再考するのに役立つテクニックに注目します。 興味のある方-猫へようこそ。



MVCとは何かから始めましょう。 ドキュメントからこの美しい図を見ました：







理論的には、すべてが非常に美しいです。図のように、ビューはユーザーのアクションをコントローラーに渡し、ユーザーは必要に応じてモデルを更新します。更新が完了した後、モデルはコントローラーに通知し、ビューを更新します。 すべてがシンプルで、すべてが機能します。 このアプローチを使用して、大規模なアプリケーションを含む数十、数十のアプリケーションを作成しましたが、iOS、MacOSだけでなく、Webアプリケーション、Windowsアプリケーションなど、このアプローチをほぼ40年間使用してきた多くのものを意味します。 それらの多くは現在このアプローチを使用しており、同時に問題は発生していません。 MVCの主な利点は、特にiOSでの使いやすさです。 UIKitフレームワークのUIViewControllerとその子孫は、「すぐに使える」多くの機能と機能を提供します。 小規模なアプリケーションを作成するには、プログラミングスキルは実質的に必要ありません。2日間のYouTube講義で十分であり、開始できます。 問題は、大規模なプロジェクトで作業する必要があるときに始まります。 パターンとしてのMVCのスケーリングはあまりよくないという多くの証拠があり、これがMassive View Controllerと呼ばれる問題につながります。



問題の原因



私の意見では、この問題の理由は次の2つです。



1. MVCは、作成する必要があるエンティティとクラス、および作成していないエンティティとクラスについて明確な指示を実際に提供しません。 特にiOSで。 UIKit MVCは最初はUIViewControllerのみを提供しますが、基本的にはそれだけです。 ビューは存在するが、最初は宣言されていない、つまり ビューの個別のインスタンスを作成することなく、UIViewControllerアプリケーションのみがその機能を実行します。 モデルと同じこと。 モデルの構造とアーキテクチャ、およびコントローラーとの相互作用は、開発者の良心と想像力に完全に依存しています。 これは、実際には2番目の理由につながります。



2.ドメイン領域の不十分な理解、開発者が必要なエンティティを割り当てることができないため、UIViewController内の依存関係と機能の蓄積。 つまり 開発者が新しい機能を追加すると、新しいエンティティを作成して既存のアーキテクチャをリファクタリングする代わりに、ViewControllerに新しい機能が追加されます。



つまり この問題は、アーキテクチャと不注意/怠慢/怠iness /無知/経験不足（下線）開発者の欠陥によって等しく発生すると言いたいです。



最初の問題の解決策



MVC問題の最初の部分を部分的または完全に解決するMVVM、MVP、VIP、VIPER、Flux（Facebook）、Riblets（UberのViper）、Clean-Swiftなどのアプローチは、ここ数年で非常に人気があります。 それらの多くは、開発者にクラスとそのクラスを作成する必要がある理由について明確な指示を与えます。 また、チームが同じプロジェクトに携わる10人以上の開発者で構成される場合は特に、チーム作業がはるかに容易になります（たとえば、Uberで150人、JustEats 20人以上、Facebookを検討するのも怖いですが、間違いなく10人以上です）。 これは、コントローラーコードをカバーするだけの多数の孤立したオブジェクトの作成を意味するという事実によるものです。これにより、チーム内で大きな損失なく作業を分散できます。



2番目の問題はまだ残っています。 ビューモデルとプレゼンタークラスでVIPとMVVMを使用し、解析とマッピングからデータベースクエリとHTTPリクエストの形成まで、複数の操作を含む1500行以上のコードを含む多くのプロジェクトに出会いました。 開発者の経験不足またはアプリケーションアーキテクチャ全体の理解不足の問題は、単にアーキテクチャパターンを変更するだけでは解決できません。 私の観点からは、単に「デフォルト」で大規模で複雑なプロジェクトをサポート/作成できる「黄金の弾丸」はありません。 いずれにせよ、これには労力、単体テスト、適切な計画、および時間が必要です。



2番目の問題を部分的に回避する方法に関するヒントがある部分



1. ViewControllerを促進する



まず第一に、良いことに、アプリケーション内のどのオブジェクトも複数の機能を担当するべきではありません（単一責任）。 多くの開発者にとって、これは明らかですが、それにもかかわらず、彼らのコードはそのような単純な仮定に準拠しているとは言えません。 多くの場合、UIViewControllerが他の全員と同じオブジェクトであること、およびモデルとビューをバインドするという1つの責任のみが必要であることは明らかではありません。 つまり ビューを適切なモデル状態に維持し、この状態を変更する必要がある場合にモデルに通知します。 私の観点からすると、この定義を超えるものはすべてコントローラーに属していません。 アニメーション、レイアウト、構成ビュー、レンダリングの変更、解析、マッピング、httpリクエスト、データベースクエリ、さまざまなレベルのオペレーティングシステムサービスなど、すべてのガベージ-これらはすべてコントローラーに属していません。 これらはどれも作成せず、コントローラー内で呼び出す必要があります。 個々のポイントの1つはナビゲーションです。 ViewControllerに複数の出口点がある場合は、ナビゲーションとナビゲーションコントロールについて検討する必要があります。 コントローラーコード全体に5〜10個の出口点が散在しているViewControllerに頻繁に出会わなければなりませんでした。 ナビゲーションの作成から個別の拡張機能へのナビゲーション、セグエのみによるナビゲーションの管理、個別のルーターエンティティの作成、UINavigationControllerからの継承など、これを編成する方法は多数あります。 しかし、それも行う必要があります。 そしてテストします。 覚えておくべき主なことは、ViewControllerは行のすべてではなく、必要なことを実行する必要があるということです。 MVVM、VIPERで使用されるエンティティについても同じことが言えます（リストはもう少し本物です）。 彼らがしなければならないことは、彼らがしなければならないことだけ、それがView-Modelなら、そしてビューのデータ表現のみ、それがエンティティなら、そしてデータの保存と変換などです（責任の例はarbitrary意的であり、著者はこれらのステートメントの完全な真実を装っていません）。 既存のクラスに新しいメソッドまたはプロパティを追加する前に、それが本当にこのクラスにあるべきかどうかを常に考えてください。



2. モデル



iOSで頻繁に見られるエラーの1つは、モデルレベルの分離がないことです。 私の観点から、そして実際にアプリケーションを成功させた後、モデルを別々のフレームワークに配置することが最善です。 ドメインを取り出すことができます。 たとえば、フードデリバリーアプリケーションがある場合は、別のフレームワークに入れることができます。たとえば、レストランとそれに関連するすべて（レストラン、メニュー、場所などで検索）、料理、配達エリアなどです。 チケットを購入するためのアプリケーションがある場合、ダースのfarmework'ovを選択できます（チケット、予約、購入、履歴などを検索します）。 各フレームワークは、個別の単体テストセットでカバーできます。 これはできませんが、それでもコントローラーとの相互作用から完全に分離されたモデルを作成しようとします。



3. 大規模な「UI」ViewController



巨大なストーリーボードに何度も出会っており（また戻ってきます）、巨大なUIViewControllersも同様です。 巨大なのはコードの量ではありませんが（これも）、UI要素の数の点では。 すべての開発者が巨大な山積みのViewControllerを見たときに自問すべきだと思う質問は、次のように聞こえます。







これはWordの空のドキュメントのスクリーンショットであり、1つのViewControllerであるとは思えませんが、多くのiOS開発者は1画面-1 ViewControllerパラダイムに従います。



別のViewControllerでユーザーの論理操作または機能を実行する画面上のいくつかの要素を選択します。 例はこの画面です。







表の各セルは個別のVCです。 作成者のアバター、作成者、および時間のタイトルは、個別のViewControllerです。 コンテンツとリンクも別個のViewControllerです。



いいね-コメント-共有-これらのコンポーネントはすべて別個のViewControllerです。



4. たくさんのUIコード



膨大なUIコードは、さまざまなコンポーネントの肥満にもつながります。 ソリューションは、ViewController内のカスタマイズではなく、UIコンポーネントのデフォルトの継承である場合があります。 または、UIを説明する拡張機能を追加できます。



5. 大規模なストーリーボード。



多くの場合、プロジェクトで大規模なStoryboardファイルに出会いました。 さまざまな詳細レベルの20〜50個のViewControllerがストーリーボードに追加されます。 最初はすべてがスムーズかつ便利に行われ、ナビゲーション全体がそこにあり、設定もそこにありますが、要件が変更されたり新しい開発者が接続するとすぐに、それは完全な地獄になります。 1つの解決策は、Xcode UI Builderをそのまま使用しないことです。 コードからレイアウト全体を作成します。



さまざまなライブラリを使用して、制約（Parus、Masonryなど）の記述を簡素化するか、ハードコア用にCGFrameを使用して、すべての方向と許可についてすべてを自分で記述します。 Storyboardを本当に使用したい場合は、プロジェクトをいくつかに分割する方法を検討してください。 理想的には、ストーリーボードには1つの責任、または1つのユースケースが必要です。 つまり たとえば、タクシーのアプリケーションがある場合、個々のストーリーボードは、タクシーの呼び出し、タクシーの追跡、支払い、一般情報などになります。 つまり 多かれ少なかれ独立した機能。 ストーリーボードリファレンスを使用すると、これは非常に便利であり、最小限のコード記述が必要です。 理想的には、ストーリーボードには3〜4個以上の個別の画面を含めないでください。 ストーリーボードが大きくなるほど、それをサポートするためにより多くの労力が必要になり、最初に理解するのがより難しくなり、ロードするのに非常に時間がかかり、開発チームで作業するのがより難しくなります。



結論



この投稿で言いたかったことは、MVCがiOS開発者の多くの問題を非難する傾向があることに気づいたことです。そして、多くの場合（上記の例で見られるように）、これらの料金はiOSに特に限定されません 多くの場合、それは開発者自身の責任であり、さらに、これらの開発者は他のアーキテクチャに切り替えるときに同じまたは同様の問題を経験することがよくあります。 大規模なVCは、MVCがスケーリングできないからではなく、開発者が制限を正しくスケーリングしたくない/許可しないために、90％のケースで発生します。



VIPER、MVVM（およびその他）は、特に開発チームで作業している場合にこれを支援できますが、すべての問題に対する万能薬ではありません。 この記事では、私自身がプロジェクトでVIPER / MVVMを使用しているにもかかわらず、MVCが非難されず、悪魔の擁護者として行動する状況の一部を引用しようとしました。 良いコードを書いてください。 すべてビーバー。