クリスマスまであと僅か。
今年は初参加で2枠いただきましてありがとうございます。@shinoutといいます。
Titanium-JP界の著名な方々にお世話になりながら医療系スタートアップを始めたJSerです。
前回と関連した内容になりますが自身の関心あるマルチプラットフォームJavaScriptの話をさせて下さい。
わかりづらかったらすみません。。
ビジネスロジック層とUI層は、分離するとよい
それは
- 規模が大きくなっても扱いやすい、変更に強い
- ビジネスロジック部分をNodeで開発できたら開発スピード早くなる
からです。
(規模が小さいときはスマートUIパターンで作って逃げ切るのも選択肢のひとつです。)
どう分けるか
モデルとその振る舞い(model)、モデルの生成(factory)、モデルのCRUD部分(repository)を
ビジネスロジックとして分離します。いわゆる「ドメイン」という部分です。
(これを綺麗に切り出すのが大変なんですがその話は割愛...)
例としてMBaaS(Mobile Backend as a Service, データの永続化に関するRESTfulなAPIを提供するもの)を利用したサービスを考えます。
この場合、データ層がHTTPを介する汎用的なものになるため、プラットフォームに依存しにくくなります(ファイルやDB直触りだと、プラットフォーム間で事情が異なる事が多いですが、HTTP Requestはどのプラットフォームも持っています)。
前回紹介したti-superagentを用いれば、HTTP RequestライブラリのsuperagentをTitaniumでも用いることができ、データアクセス部分も含めて Node.js / Web / Titanium で動くようになります。
開発/テストはNode.jsで行うことができ、PDCAサイクルを素早く回すことができるでしょう。
特にネットワークを介したテストがNodeでできるのは大きな利点です。
ドメインは複数のプラットフォームで再利用可能
MBaaSのほかに管理用のサーバーが必要になったりだとか、Webアプリが必要になったという需要はあるでしょう。
その際、モデル含めたビジネスロジックの再定義は必要なく、そのままドメインを使えばよいです。
下記に概念図を載せました。
browserifyやtisomorphicを用いることで、require()等の差分を吸収し、
各々のプラットフォームで動かすことができるようになります。
Alloyのmodel(Backboneのもの)はどうする？
現状では使っていません。利用する利点もあるとは思いますが、
- 開発スピード
- 再利用
という点で、プラットフォーム依存をなくすことのほうが重要と考えています。
例えば皆が気になっているCordovaやReact Nativeにも同様にドメインを再利用できるので、
簡単に既存のプロジェクトをこれらのプラットフォームで試すこともできるでしょう。
まとめ
- UIとビジネスロジック(ドメイン)を分離し、ビジネスロジックは汎用的なJSにするとよい。
- 汎用的なJSはNode.jsで開発/テストするとサイクルが早い！
- データ層がネットワークにあると多プラットフォーム展開しやすい！
- 分離されたビジネスロジックは、あとで別なプラットフォームで再利用できる！