Readability over Convention

最近、流行のS2Daoを試してみた。
S2DaoはCoC(Convention over Configuration:あるルールでコードを書けば設定ファイルなんて要らないZE☆)と言う思想で、設定ファイルを極力書かずにORマッピングができるので非常に便利だった。アクセステーブル名はクラス名、カラム名はプロパティ名、DAOの検索メソッドはselectから始まるメソッドなど。制限も少なく、さくさく書ける。あとはフレームワークが全部してくれる。iBATISとかHibernateと比べると圧倒的に楽だ。

が、Ruby on Railsで流行りだしたCoCブームも一段落すると欠点も見えてきたようだ。
CoCだと規約(Convention)を理解していないと、何をやっているか全くわからないという点だ。(全くというのは言い過ぎか)
CoCはおそらく開発者のリズムを崩さないと言う要素を最大化する思想なので、精通した技術者が少人数でガシガシコードを書くには最適だと思われる。
しかし現実のプロジェクトでは人の入れ替わりは激しいし、人によって技術の差も大きい。
よってそんなときCoCは足かせとなってしまう。

と言うことで、それは問題だ!と思う人向けにS2JDBCと言うのが出てる。
こちらは既存のフレームワークのリズムの悪さと、CoCの規約まみれの解決策として可読性を最大化するように設計されているようだ。
こちらはまだ全然使っていないので、何とも言えないが、コードを見る限りよさげだ。
たとえば検索クエリは以下のようになる。

S2DaoよりもSQLを細かいところまで自動生成してくれるようなので、S2JDBCの方がさくさく書けるかもしれない。

Web系Javaはこういう「こんなん便利じゃね?」「いやいやこういうやり方こそスマートだ!」みたいなのがどんどん出てくるので面白いな。
おそらく、全部のフレームワークの良いところばかり集めたバランスの良いフレームワークが一番なんだろうけど、今はまだ試行錯誤の段階でRuby on RailsやS2Daoのような提案手法に特化したものが出尽くすのを待つ時期なんだろう。

No Comments

Post a Comment

コメントを投稿するには、下の計算の答えを入力する必要があります。答えは半角数字で入力してください。 * Time limit is exhausted. Please reload the CAPTCHA.