iOSアプリクラス設計メモと振り返り

公開日:2019-05-05
最終更新:2019-05-05

初めてiOSアプリ開発をしました。
そこで悩んだ「iOSアプリ開発におけるクラス設計」について、自分なりにどう考え、結局どういう形で実装したのかをメモっておきます。

調べるといろいろ出てくる

「とりあえずこうしておけばおk」みたいなRails思想は無いので、(あれば楽っちゃ楽なんだろうけどw)どれかを選択するなり自分で考えるなりせねばならなそう。
以下、調べてみたものの所感

MVC

  • iOSアプリ開発では、Cの肥大化がよく問題視されるっぽい。
  • 確かにControllerに書く内容として、「viewの表示」「ユーザーからのアクションに応じた処理」「Modelとのやりとり」とたくさんあり、ごちゃごちゃすることが想像できたため採用しないことにした。

MVP

  • P=Presenter
  • パッと見Controllerが無いように感じるが、Controllerも存在する。MVCPやんけ
  • PresenterはModelとControllerの間に立ち、「ユーザーアクションによる処理」「Modelを介したデータのやりとり」を行う
  • iOSアプリ開発におけるController(ViewController)は、Controllerと名を冠しているものの、極めてViewに近い位置に居るっぽい
  • MVCと比べ、Controllerの肥大化は防げそうだがPresenterが肥大化しそうな予感

MVVM

  • フロントエンド界隈では有名なアレ
  • Viewの表示内容をModelとDataBindingする。(Presenterの場合は、都度DataをViewに引き渡す)

VIPER

  • View, Intaractor, Presenter, Entity, Router
  • 多分ある程度規模が大きめのアプリだとワークしそう
  • 機能の実装に対して、コード量が増えそう(MVCやMVPなどと比べて)
  • 役割分担がはっきりしているので、迷いが少なくなりそう(うーんこれは誰がやるべきなのか・・・、が減りそう)

で、結局・・・

MVPを採用することにした。
<理由>

  • VIPERよさそうだったが、アプリの規模がそこまで大きくならないのと、ある程度スピード感が求められる案件だったため、今回は見送り(いつかやってみたさ)
  • MVCはやはりCの肥大化が気になるため却下
  • 残るはMVPかMVVMだが、MVVMはフロントでやってるため別のアーキテクチャに触れてみたかったことから、MVPを選択した

しかし、そのままMVPを使うのではなく、自分なりに少しアーキテクチャを変更してみた。
具体的には、ModelをVIPERでいうところのEntityとし、Entityを取得するためのクラスとしてDataManagerなる層を導入した。
View(ViewController) : Presenter = 1 : 1だが、Presenter : Model = 1 : N となるため、PresenterがたくさんのModelとやりとりして云々し始めるとすぐにごちゃごちゃするのではと想像した。これでは、MVCでCが肥大化する部分をPに追いやっただけに過ぎなくなってしまい、MVCを却下しMVPとした意味が薄くなってしまう。
また、Modelがデータ(レコード)の化身となり、それが自分自身を取得し返す?ようなModelの在り方に違和感を感じ、「データ本体」と「データを取ってくる人」が別々にあるほうがよいのではと考えた。
これらの理由から、DataManager : Model = 1 : 1となるDataManagerを定義した。また、Presenter : DataManager = 1 : Nとなる。
データの取得処理をDataManager側に置くことで、Presenterの中からデータ取得ロジックを追い出し、複数のModelを扱うような場合でも比較的見通しよくコードが書けると考えた。

実装してみて

  • DataManagerの導入により、MVPとVIPERの中間ぐらいのアーキテクチャになったと思う。役割分担が(VIPERほどではないが)明確なので、迷いが少なく、開発スピードが上がったと感じた
  • DataManagerという命名がよかったのかは謎である。自分でももっといい命名があったのではと思っている
  • Presenter : DataManager = 1 : 1 のときはPresenterとDataManagerの実装が似たような形になるので、「本当にDataManager必要なの?」と思うことが何回もある(冗長に感じる)
  • Railsをずっとやっているので、アーキテクチャを自分で考えて実装、という経験を久々にやった。楽しい!(チーム開発でないからできることなのかもw)
記事が少しでもいいなと思ったらクラップを送ってみよう!
19
+1

よく一緒に読まれている記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる

技術ブログをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

技術ブログを開設する

Qrunchでアウトプットをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

Markdownで書ける

ログ機能でアウトプットを加速

デザインのカスタマイズが可能

技術ブログ開設

ここから先はアカウント(ブログ)開設が必要です

英数字4文字以上
.qrunch.io
英数字6文字以上
ログインする