Clever Geek Handbook

MVPからVIPERへ。 パート1：MVP







少し前に、私は翻訳を発行しました。 なぜVIPERがあなたの次のアプリケーションにとって悪い選択なのか 。 そして、しばしば起こるように、翻訳者の意見は、元の記事の著者の意見と一致しませんでした。 したがって、この投稿では、自分のプロジェクトにVIPERを導入しようとしている（まだ試みている）方法を簡単に説明します。







前のプロジェクトで作業を開始したとき、チームには2つのゼロのモバイル開発者がいました。1つはAndroid用のバージョンを作成し、2つ目はiOS用に作成しました。







当然、iOSバージョンはApple自身が推奨する古典的なMVCパターンに基づいて作成されました。







私はビューを持っていました： 9000以上のかなりの数の画面を持ち、次のような「お気に入り」のストーリーボード：













私はモデルを持っていました-クラス、設定を保存するため、ユーザーデータ、内部データベースに保存されたいくつかのデータ。







そして、ストーリーボードの各画面にView Controllerがありました。 View Controllerには、モデルからの通知（リクエストに応じたデータの受信またはデータの変更）とともに、ホストされたユーザーアクションハンドラーが必要です。 しかし、実際には、次のようなことがそこで起こりました。 







Networking.request(.POST, withURL: serverAddress, andParameters: parameters) { (dictResult, error) in if let dictResult = dictResult { // some actions with view if let rates = dictResult["rates"] as? [AnyObject] { for rate in rates { if let rateDictionary = rate as? JSONDictonary { let result = Result(jsonDictionary: rateDictionary) self.resultsArray.append(result) } } } // some actions with view } else { if let error = error { DispatchQueue.main.async(execute: { self.showError(error) }) } } }


一般的に、私は自信を持ってModel View ControllerからMassive View Controllerに移行しており、それについて何かしなければなりませんでした。







私はモバイルアプリケーションの可能なアーキテクチャの研究を始めました。もちろん、私はすぐにCleanアーキテクチャパターン（本質的にVIPER）が好きでした。













The Book of VIPERの写真







私はこのパターンを調査するために数日間大胆に過ごしました。 いくつかのビデオチュートリアルに目を通し、その上に多くの簡単なサンプルアプリケーションを作成しました。 また、モジュールファイルを生成するための便利なスクリプトも見つかりました。1つのモジュールには約12個のファイル（プロトコル、コンフィギュレーター、直接クラス、ストーリーボード、単体テスト）があるからです。 しかし、すぐに「額に」VIPERを紹介しようとすると、多くの時間を失うことになります。 結局のところ、習慣から外れて、私はすべての層間での責任の正しい分割にあまりにも多くの時間を費やすことになります。 そして、私はより簡単な方法で、責任を徐々に共有することにしました。













しかし、UIViewControllerがビューであると言ったらどうでしょう。

それが私がMVPを取り上げた理由です。 UIViewControllerがビューレイヤーを参照していることを理解するのが最も困難であると同時に最も簡単です。 UIでのみ機能するはずです。UIに関連するユーザーアクション（ボタンの押下、テキスト入力など）から取得し、UI自体の表示を変更します。 最初は複雑に見えましたが、View Controllerに必要なものをすべて入れるのに役立ついくつかの簡単なルールを考え出し、同時にそこに余分なものは何も入れませんでした。







  1. View ControllerのすべてのメソッドとアルゴリズムはUIで動作するはずです。 UIKitを使用せずに動作できるメソッドまたはコードの一部を見つけた場合、このメソッド/コードブロックはここに属さないことに注意してください。







  2. プレゼンターにとって、すべてが正反対です。UIKitが必要な単一のメソッドが存在するべきではありません。 そのようなメソッドが検出された場合、これらのコードのセクションを慎重に検討し、View Controllerに送信する必要があります。







  3. View ControllerとPresenterには、署名されたプロトコルがあります。これらは外部インターフェイスです。 外部から呼び出せるメソッドを定義します。 したがって、突然、View Controllerで同じView Controllerのインターフェイス（プロトコル）からのメソッド呼び出しが表示される場合、このメソッドはView Controllerではなくプレゼンターにある必要があります。


MVPに切り替えることで、主なことは、エンティティ間で責任を共有することです。 これまでのところ、UIの操作を他のすべてのものから分離しているだけですが、先に、VIPERはまだ私を待っています。 おそらく古典的で、おそらくより階層的です。







私は彼にすぐに着き、私の話を続けてくれることを願っています。







More articles:


All Articles