WScore：展望（2013年9月）

WScoreフレームワークの開発方向について、考えてみる。

１）現状のスタイルを踏襲する

一番無難。
また新しいことを試すのも楽。

なので、WScoreの開発は続けてゆくと思う。
DIをどうするか（Ray.DIに乗り換えるか）など、結構基本的な部分で悩みがあるのだけど、そういうのも含めて、自分の勉強のためになると思っている。

本音を言えば、最初はフルスタック可能なフレームワークを作る気はなかった。それが、勉強のためという理由で自分で開発したり、１００行ぐらいでできそうかも、と思ってしまったとかで、機能が膨れ上がっていった。 

でもコード量は１万５千行ぐらいと比較的小さめなFWだと思う。

２）Cena on Doctrine 2

Cena技術は、本来どんなORMの「薄いマッパー」として動く、はず。
なのでDoctrine 2上でCenaを開発してみたい。

実は、これを最初に検討した。
エンティティの状態が知りたいので、UnitOfWorkの3000行のコードを見ているうちに、気がついたらwsCoreというレポジトリをgithubで作っていたのだった…

あれからDataMapperやCenaについての知識も増えたし、もう一度試してみたいと思う。

もう一度Doctrineのコードを見たら、「getEntityState」というメソッドを発見。これを使えば楽に作れる気がしてきた。どうして一年前に見つからなかったのか謎ではあるが。 

でも、Cena on Doctrineができたら、WScoreを使ってくれる人はいなくなるなぁ、と思いつつ、どちらにしろ使ってくれる人は殆どいないと思うので、これが正しい道だと思う。

３）クライアント側の開発（JavaScript）

クライアント側のライブラリを開発する。
つまりJavaScriptを書くということ。

前にCena-DTAというのを作ったことがある。
初めての本格的JS開発ということで、jQueryのプラグインとして開発したので、複雑な動きに対応しづらくて大変だった。また当時はWebSqlしか使えなかったので、SQLを使って作った。

今ならBackboneかAngularを利用して、モデルか何かのプラグインみたいな形で開発してみたい。それとIndexed Databaseを使ってみたい。


４）XaaS

開発は楽しいのだけど、世界はすごいスピードで進んでいる。
BaaS（Backbone As a Service）など、こういうところでCenaを使ってほしいと思ってたレイヤーがサービス化している。

今のペースで間に合うような気はしないが、何かはしてみたい。