Hatena::Groupangelos

Angelos in Action RSSフィード

Fork me on GitHub
 | 

2009-03-08

CatalystのRoutingの良い点/悪い点

03:47 | CatalystのRoutingの良い点/悪い点 - Angelos in Action を含むブックマーク はてなブックマーク - CatalystのRoutingの良い点/悪い点 - Angelos in Action CatalystのRoutingの良い点/悪い点 - Angelos in Action のブックマークコメント

CatalystのRoutingの良い点は、

  • Routing情報をrouting情報とcontrollerに分離させずにDRYにかけるという点が優れています。
    • URLとControllerをマッピングする情報が、Controllerにかかれているため、必要となる情報の距離が近いという点で、記述漏れとミスが減るという点が素晴らしいです

一方悪い点は、以下の通りです。

  • Routing情報の一覧性にかけ
  • Routingを変更するのにControllerを書き換える必要があり
  • Routing方法を変えにくい

Railsmerbでは、Routing情報とControllerを分離しているのですが、それによるマッピングミスの問題はscaffoldでカバーしています。

個人的には、

  • Routing情報とControllerを分離することのメリットがある
  • Routing情報のデフォルトの方法として、RESTfulなRoutingができるようにしたい

と思っているので、angelosではかなりRailsよりの仕組みを採用しています。

Routing部分は、WAF毎にデザインの仕方が異なるデザインポイントの一つなのではないかと思っているので、これについては他のWAFのこんなのがいいよ!という意見があれば、是非きいてみたいですね。

最近少し思うのは、CatalystのChainedの記述方式に問題があるだけで、あの記述方式をおきかえれば、ControllerにRouting情報をかくという解もありなのかもしれないなぁと少し思う今日この頃です。

# 一応補足しておくと、CatalystではCatalyst::Controller::Resorucesを使う事で、Chainedカオスを避ける事はできます。

Mouse++

02:45 | Mouse++ - Angelos in Action を含むブックマーク はてなブックマーク - Mouse++ - Angelos in Action Mouse++ - Angelos in Action のブックマークコメント

Mouseはメモリの使用量も小さく、startupも早く、かつ実行速度もClass::Accessor::Fastと同等で、かつ綺麗にOOな仕組みがかけるという点で、これを使わない手はないなぁと思っています。syntax sugarを新たに作るのが嫌いという理由以外、これを使わない手はないなぁと思っています。

そんなこんなで、Mouseを使っていると全てをMouseにしたくなるという衝動にかられるわけですが、angelosは全体的に使用モジュール含めMouseばかりになってきました。これは、MouseにXSのアクセッサができることを期待してそうしているというのもあります。

# FormValidator::SimpleもFormValidator::Liteにして、全部統一してみよっかなぁ。I18N系はData::Localizeに置き換えてみました。APIも綺麗で素晴らしいです。

CatalystとRailsにみるフレームワークの設計思想

02:11 | CatalystとRailsにみるフレームワークの設計思想 - Angelos in Action を含むブックマーク はてなブックマーク - CatalystとRailsにみるフレームワークの設計思想 - Angelos in Action CatalystとRailsにみるフレームワークの設計思想 - Angelos in Action のブックマークコメント

Catalystの良かった点は、ありとあらゆる所を拡張できるように設計してあったことなんだろうと思っています。プラグインの方式に難があるというのはさておき、それは些細な点であって、一番多分上手くいかなかった点は、フレームワークとして適切なデフォルトセットを用意しなかった点なんだろうと思います。

これらの点を顧みると、フレームワークは、以下のような方針を持つべきなんだろうと思っています。

  • コアは小さく
  • プラガブルな拡張性を持つ
  • 適切なデフォルトを持つ
  • 全体として一貫性を持つ

ただ、Catalystをみればわかるように、なんでもプラガブルにするとプラグイン毎に違うスタイルの実装が登場し全体の一貫性がなくなり、ポリシーがまとまりにくいいう問題点があります。また、適切なデフォルが欠けていたために、どのプラグインを使うべきかなどを含めて情報が散乱してしまったことも問題でした。この適切なデフォルトという概念は、Railsなどを見るにつけ重要だなぁと思っています。

要するに、Catalystで上手くいっていない点は、

という点で、その他の点に付いてはとても上手くいっているように思います。

一方、Railsフレームワークに必要な全ての機能をて密に統合して一貫性をもたせ、その一貫性の持たせ方が非常に美しかったために成功したのだろうと思っています。これは全てを綺麗に統合しきったDHHのセンスならではのフレームワークだったとも言えるとも思います。ただ、密に結合したフレームワークは、用途を外れると使いにくくなり、よりよいモジュールがでてきたときに置き換えができないため、仕事で使うときには困る点もでてくるとはいえ、Railsがベストのフレームワークとはいいきれないのだと思います。

要するに、Railsで上手くいっていない点は、

  • コアは小さく
  • プラガブルな拡張性を持つ

の点で、その他の点についてはとても上手くいっているように思えます。

このようなレベルでのポリシー一つをとってみても、フレームワークにはそれぞれ良い点・悪い点があります。個人的には、PerlプラグインシステムはCPANモジュールの豊富さもあいまり、非常に強力で面白いのですが、同時に利用者視点での問題点も抱えていると思っています。

WAFの設計ポリシーというのは、こういうところを一つとってみても非常に難しく、コードを読むにつけ勉強になるなぁと思うのです。多くのフレームワークには、そのフレームワーク設計者の思想があり、そこにフレームワーク設計の面白みがあると思う今日この頃なのでした。

# WAFについていえば、WAFを構成する個々のデザイン一つとってみても、設計上の判断が数多くありとても面白いので、それはYokohama.pmなどで少し解説できたらなぁと思っています。

 |