読者です 読者をやめる 読者になる 読者になる

スマホアプリのアーキテクチャについて(MVC)

スマホ開発

スマホアプリのアーキテクチャについて、どうあるべきか、ですが

世間ではMVCだ、MVPだ、MVVMだと人それぞれ思うところがあるようです。

また、一番メジャーなMVCにフォーカスしてみても、Model,View,Controllerそれぞれが何を指すかが、少々ブレ気味。

恐らく、元々WEBアプリをやってた人/やっていない人など、それまでの経験則も影響しているものと思います。

自分自身は、WEBアプリのMVC概念は無いため、とりあえずスマホ用にどうあるべきか、世間の皆様の意見も取り入れながら整理しようと思います。

 

 

とりあえず、スマホにおけるMVCの定義をまとめてみます

・View

画面を表現するレイアウトファイル(ボタンやテキストビューなど、部品コンポーネントの配置も含む)を指す。

・Controller

Androidでは、Activity(fragment)、iPhoneではViewControllerの単位のクラスを指す。

 

まず、上記だけで一旦整理しようと思います(Model抜きで)。

何故かというと、Modelは一種の概念であり、スマホアプリを作る構成単位として、自動的に出てくるモノでは無いためです。

例えば、組み込みソフトでのレイヤ構造(アプリ/ミドル/ドライバ)と同じような感覚で、アプリ、ミドル、ドライバも役割に応じてソフトの開発者が設計時に定義するものですよね?Modelも同じで、ソフトの開発者が設計の際に検討/定義するものです。

というわけで、逆に言い換えると、ViewとControllerについては、必然的に決まるモノです。どう必然的に決まるかというと、画面仕様から。

A画面、B画面、C画面とあったら、

Viewは、Aレイアウトファイル、Bレイアウトファイル、Cレイアウトファイル

Controllerは、Aコントローラ、Bコントローラ、Cコントローラ

となります。

ViewとControllerは無いと、そもそもシステムの制約上、アプリが作れません(画面無しのアプリなど一部例外はあります)。

で、自動的にViewとControllerが定義出来たら、次のステップ(設計)でModelの検討に入ります。

・Model

モデルの検討は、各画面で行われるべき処理のうち、画面に依存しない処理の固まりを抜き出すイメージです。例えば、通信やデータ管理の部分です。

じゃあ逆に画面に依存する処理は何やねんと感じる方もいるかもしれないので、念のため。画面上に表示してあるテキストの更新や、画面上でのタップやフリック操作、ボタン押下時のイベントの補足等がそれに該当します。言い換えると、コントローラにしか出来ない処理です。

 大きくはこんな感じですが、あとはどれくらいの粒度(さじ加減)でModelを抽出するかです。

一般的に言われるセオリーとしては下記のような感じでしょうか

Controllerは肥大化させず、イベントハンドリングに徹する

・ModelはControllerに依存させない

下記に良い説明が載っていました

qiita.com

安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してアプリケーションとしてくみ上げる部分が一番安定していないというようにとらえた。

なので、ModelはViewやControllerから依存されるが、Controllerは依存されない。その他の関係はイベントのように抽象度が高いものを使っている。

 要はブレ易いモノに依存するな、ブレ難いものに依存しろ、という事ですね

 

まだまだ理解が曖昧な部分もありますが、今回はひとまずこんなところで。

※書いといてなんですが、本内容が必ず正しいというわけではなく、自分の脳内整理も兼ねているので、あくまでもご参考程度に。こういう解釈のほうがベターとかありましたらご意見よろしくお願いします