ブルーオーシャン戦略

ということでひさしぶりにひがさんblogを覗くと
seasar2.5の文字が・・・
うお・・・ながれがはやい・・・
キャッチアップできていないのに

まぁそれはそれとして内容をみてみると、
RubyOnRails的な統括的フレームワークを目指しているような印象ですね。
アプリケーション全体に対して提案できるフレームワークとして
期待できるかもしれません。
Viewに関してはPage駆動が進み、それこそClickやってる人にはなじみ深いのかな
もちろんtoStringでHTMLの描画はしないだろうけど。
DBに関してはHibernateのCriteriaが好きな人にはなじみぶかそうです。

つまり僕には期待できるフレームワークになりそうな。

publicフィールドに関しては、特に賛成も反対もなくですね。
Clickで多少慣れているというのもあるし、
そもそもプレゼンよりで、本気で隠蔽の必要な情報というのはないと思うし。
大概setterも機械的に用意されるし。
通常のVOに関してはカプセル化の概念に当てはまらんと思うし。
といった感じですね。
ただまぁ若干の気持ち悪さは除けないのと、
規約をどうするのかなぁってのが気になるくらいですね。

そんでもって、肝心の無用の長物だと思っている
DIに関しては面白い記載が。
「インターフェースは基本不要」

これです。
これ
＞１インタフェース１実装ならほんと不要です。
モックが必要なら継承して作れと。

いや。まじで。
テストのしやすさでDIを勧めるイミがわかりません。
簡単にモックの作成できるほうがテストケース見やすくていいんですけど。
ってこれはただの思い込みか？（まぁ知らない人の思い込みということで）

ってのはさておき、
不要なインタフェースはちょっと・・・ね。
拡張しやすさも重要ですが、本当にそこに拡張性必要ですか？
と改めて問いかけたい。

そして定数インタフェースはやめてください。
適切な定数をインタフェースになってればいいけど
ほぼアプリケーション共通定数インタフェースってなんだ！
はい。まったくSeasar関係ない愚痴です

ってぼやきはさておき、
無駄なものは切り捨てる。
統括的なフレームワークとして選択肢に出せる
点では期待度大です。
当然要求に応じて必要な部分はサブプロジェクトを組み合わせて拡張できるだろうし。
リプレース系プロジェクトではなく
スクラッチプロジェクトでは力を発揮しそうな感じです。

しっかし。。。うーんDIか・・・
でもそれを差し引いても期待してよさそうです。
というわけでざっと資料を流しよみして
勝手な思い込みでの第一印象でした。

Seasarの勉強でも本格的にはじめようかなぁ・・・
本気のDI部分を・・・

なーんて久々に思わせるような発表でした。