mixiのアプリの設計がよく分かるブログ - スマートフォン開発研修教材の補足

こんにちは。Android の横幕です。Android が好きすぎて、来る日も来る日もアプリの実装が頭から離れず、毎日7〜8時間ほど睡眠をとっていますが全く疲れがとれた気がしない今日このごろです。はやく iOS のアプリ開発を覚えたいですが、まだ NSLog の使い方を覚えたばかりです。

さて、先日スマートフォン開発研修教材の公開についてでも触れましたが、Android・iOS のアプリ開発を始める人向けのトレーニング資料を公開しましたところ、以下のブログのような反響をいただきましたので、この場でもって回答をさせていただきたいと思います。

mixi��アプリの設計がよくわからない
http://yamitzky.hatenablog.com/entry/2013/06/19/173713 に遷移します

設計思想の基本は MVC

iOS も Android も、フレームワークとしては MVC の設計思想に基いて作られています。

この中でも特に、iOS であれば UIViewController が、Android であれば Activity や Fragment が、それぞれ Controller に相当し、Model や View の操作をします。

また View とは、UI 上の各部品のことを指します。実際にユーザが指で触れることが出来、様々な入力に応じて自分自身の表示（状態）を変えたり、入力イベントを Controller に伝えたりする役割を持ちます。

さて、ユーザはこの View の操作を通して、様々な目的を完遂しようとします。
たとえば、アプリの設定を変え、保存したり、mixi などの SNS につぶやきを投稿したり、予定を変更したり。

これらはユースケースと呼ばれ、人とシステムとのかかわり合いを示し、ユースケース図によって表現されます。そしてこのユースケースを実現する役割を持つのが Model です。

ビジネスロジックとデータ構造

Model には主に、どのような種類のデータを扱うか、という話と、そのデータをどのような手続き（ビジネスロジック）で扱うか、という話が含まれます。

私たちはこのうち、どのような種類のデータを扱うか、という点を Entity と呼び、特別にモデルとは切り離した名前空間を与えるように設計しています。

Entity はデータ構造ですので、メンバ変数と Getter・Setter メソッドのみが定義されています。ビルダーパターンを用いて、直接的にセッターを定義しない場合もあります。

一方、私たちは、Entity をどのような手続きで扱うか、という点を Model として扱っています。

よって、受け取った Entity を元に実データを生成したり、読み取ったり、変更したり、削除したりするのは Model の仕事になります。

たとえば、入力されたアプリの設定データを Controller から受け取って、それを保存する、という役割や、つぶやきの入力と設定に基いて、複数の SNS につぶやきを投稿する、と言った具合です。つぶやきを編集して変更を加える、という操作も、つぶやきのデータ構造に、つぶやきを一意に識別可能な ID があれば、それを元に Model の中で変更を加える手続きを実行できるようになるはずですから、Model の仕事と言えます。

ビジネスロジックとデータソース

Model の扱う話の中には、データベースやファイルなどの話は直接には出て来ません。なぜなら、Model はユースケースを実現するためのインタフェースを持っているだけなので、どの永続化の手段を用いるかどうかは別の話だからです。Model の中に、永続化の手段が隠蔽される、と言うことも出来るでしょう。

私たちは、この、永続化の手段を扱うものを、データソースと呼んでいます。

データソースには、MySQL や SQLite などのデータベースやファイルの他、ネットワーク越しのクラウドや、サーバサイドでは memcached のようなキャッシュの仕組みもこの中に含まれます。

それぞれのデータソースは独立しており、Model が任意の組み合わせで利用できるようにします。

たとえば、つぶやきの投稿というユースケースで考えてみると、Web サービスの API にアクセスする為の手段を用いてそれを実現する、というのも1つの手段ですし、あるいは、これと組み合わせて、端末側にデータベースを用意し、キャッシュとして使う、ということも考えられます。

いずれにしても、どのような永続化手段を用いるか、というのは、Model の中で適宜決めればよいので、手続き上でいつでも手段が組み換えが可能な設計としておくのが良いでしょう。