0
1

More than 3 years have passed since last update.

既存のプロジェクトをMVPにして気づいた点、注意点

Posted at

 

はじめに

現場ではCocoaMVCだったのですが、まぁ今後のプロダクトでどのよーなアーキテクチャが良いか
比較して、実際に既存のプロダクトの1画面作り変えてみました。
実装→iOSチームでレビューの過程ででた所感や気づきを共有します。

MVP自体はネットにゴロゴロありますし、
MVP自体についてざっくり知りたい方はアーキテクチャ比較も投稿したのでよければ。

ざっくり所感

  • 各コンポーネントの役割が決まっているので、読みやすい。
  • ユーザーの入力部分について(ViewController)とPresenter,Modelと作業分担しやすい。
    ただ、作る際にある程度認識合わせ、ルールを考えておかないと実装漏れやコンフリクトのような問題が起きそう。

  • ViewControllerの肥大化は抑えられるが、FatPresenterになってしまう恐れがある。
    例)Presenterは画面遷移やViewの操作も全て行うのか。
      今回は全部行うようにしたが、「Delegate多すぎ」って意見もあったので。

  • viewDidLoadなどのライフサイクルイベントもviewからのユーザー入力としてprotocol化したけど、分かりにくいという意見もあった。一応サンプルではそうなっていたし、PresentationLogicも全てってなった時にそのほうが自分的には抵抗なかった。

  • 2人開発では必ずしも取り入れるものではないと感じた。

  • viewController自体は100行~くらい減らせた。

  • FatViewControllerの解消、可読性の向上は少し実感できた。

  • UIテストしやすい。

  • 既存のコードの変更は学習しながら1.5日くらい。慣れればもっと早くなる。

  • Cocoa MVC,Delegate, protocolを理解していればそんなに学習コストは高くなさそう。

最後に

可読性ってそのターゲットによって違うと思うので、逆にMVPのパターンを知らないと見辛くなる場合もあるんだなと。
MVVM編も投稿しようと思います。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1