これに従う必要は無いがこうしておくと後々やりやすいよってやつ
クライアントサイドとは言え、大規模で保守性の高いアプリを作るなら、アプリケーションは次の5つのレイヤに分けておいた方がいい。
View 層
- View は、ユーザーとのやりとりを行う。
- 金額のデータに ¥ や , を付加したり、リストの表示、メニューの出し入れなどのいわゆる「プレゼンテーションロジック」もこのレイヤが担当する
Controller 層
- Controller は、View と後述の Service をつなぐ部分。ここにはデータのバインドとページ遷移の簡単な if 文を除き、ほとんど何も記述されない。
- ほとんど何も記述しない。
- ほとんど何も記述しない。
- ただただ View と Service のパイプ役に徹するべきである。
- ほとんど何も記述してはいけない。
- 30行超えたら危険信号、50 行を超えるようなら設計がおかしいと思ったほうがいい。
- 今やってるプロジェクト（結構大規模）の controller の行数調べたら 29 ファイルで 765 行、平均 26.38 行だった。
Service 層
- Service は、アプリケーションそのものを表す。
- Controller を介して上がってくるユーザーからの要求を元に、後述の Model 層から適切なデータを取得あるいは Model 層へデータの保存を依頼する。
- 複数の Model が関わるようなビジネス、例えば ある「商品」を「マイフレンド」に「プレゼント」したい、という時に、productModel, friendModel, presentModel などからデータを受け取り、giftModel に保存する、みたいなことをこの層で行う。
Model 層
- Model は、Service に対してデータを提供する。
- そのデータの出所を隠ぺいする役割を持つ。つまり、そのデータが、API を経由して外部から得たのか、LocalStorage に保存してあったのか、などを覆い隠す。
- Model と Service を分離することで、Service はデータの出所を意識せずに済む。
- 複数のサービスから呼ばれるようなロジックを Model に書くことで、コピペエンジニアの鼻を明かすことが出来る。
API 層
- API 層は、API 通信を行って外部とやりとりをする。
- シングルトンにしがちだが、クラスを提供して都度生成のほうが書きやすい（この辺については別記事にまとめます）
今スタバ（本当はマック）でドヤリングしてるんですが電池が無くなってきたのでここまで。
次回は各サービスの命名規則についてとかを書きます。