JavaMVCフレームワークたち（about Java MVC framework）

JavaのMVCフレームワークはたくさんある。



Struts、Spring、Seaser2、Wicket、JSF、Tapestoryなどなど。。。。






正直、フレームワーク、たくさんありすぎて 分からない。




もし、アメトーークに「Javaフレームワーク芸人」とかあるとしたら、
僕は 蛍原のポジションである。
なので、このエントリもそういう目で見てください（苦笑）


実際、僕自身が使用してきたのはStrutsがほとんどで、
Seasar2をちょっと触ったことがある程度である。




ということで、様々なMVCフレームワークの概要を最近調べている。
今回は調べながら感じたJavaのMVCフレームワークの体系をまとめてみたいと思う。

○始まりはStruts

気づいたのは、MVCフレームワークの変遷は Strutsから始まっていること。
StrutsがJavaのMVCフレームワークという概念を確立したという意味で
やはり成果は大きいのではないだろうか。良くも悪くも。

JavaのMVCフレームワークはStrutsをデファクトスタンダードとし、Strutsからの教訓を得て、
改善、継承を行いながら新たなフレームワークが開発されている。




例えば、SpringやWicketといったものだ。
（最近ではPlayとかが流行りなのかな）

○キーワードは「XML地獄」、「手続き型」、「オブジェクト指向」、「コンポーネント」、「リクエスト駆動」

・XML地獄


そんな「Struts以降」に共通するキーワードがXML地獄からの脱却だと思う。
設定ファイルを避けるかの如く、Spring、Wicket等のフレームワークはDI機能を盛り込んだり、
アノテーションベースにしたり、コンポーネントベースにしたり。
とにかく、設定ファイルから離れることが1つのテーマになっている。

設定ファイルの面倒くささはStrutsを一通り使ってみて初めて分かる感覚だと思う。






・手続き型かオブジェクト指向か


Strutsの場合、例えば、画面遷移処理が増えるたびにstruts-configが膨らむ。
エラーメッセージなどはプロパティファイルから。
それはつまり、Javaで開発をしているはずなのに、ある種手続き型の言語を使用しているかのような錯覚に陥る。Strutsに縛られてているかのような。
Java本来のオブジェクト指向とは何か、という点がStruts以降のフレームワークのテーマとして内在化している。











・リクエスト駆動かコンポーネントベースか


Webアプリケーションの開発である限りHttp通信のリクエスト/レスポンスのライフサイ クルは避けられないものである。
だからこそ、サーブレットコンテナのようなものが存在するのだろう。
一方で、Wicketなどはそういった、Http通信を意識させないようなフレームワークを
目指しているように感じた。
背景には、オブジェクト指向を目指すということがあるのだろうけれども
オブジェクト指向で開発するか以前に通信規約に沿った設計というのも重要であると思 うし、
難しいところではある気がする。

○Ruby On Railsという存在

どうやら、近年のフレームワークを語るうえで絶対的な存在になっているかのような感 じがする。
それというのは、Ruby On Railsそのものよりも、Railsの2つの思想に対してのリスペクトが強い。



・繰り返しを避けよ（DRY : Don't repeat yourself）



・設定より規約（Convention over Configuration）




Railsを良いMVCモデルとして紹介されている記事が多い分、
いわゆる「銀の弾」のように万能なフレームワークと印象付けられてしまっている感も 強いが、
そういったわけではない。と思う。（分からないので、ためしに一回使ってみたい）

○番外 Java派生言語

JavaのMVCフレームワークとは少し離れてしまうが、
Scala、Groovy、JRubyなどの普及はすごい感じがしている。
言語自体がそこまで歴史が深くないし、
フレームワークも最近？になって新しいものが出てきている。
(PlayとかGrailsとかJRuby on Rails)

Javaからの派生で、インタラクティブな言語とそれにかかるフレームワークが
使用されるケースも増えている。

Scalaとかは関数型言語なわけだし、「もはやJavaじゃないじゃん」と言われればそこまでなのだが、
Javaのフレームワークを考えるうえで、相互に影響を与えあう可能性の高い分野なので、
今回番外ということで章立てした。
(twitterとかScalaで動いてるところもあるらしいですね)

○まとめ

どのフレームワークにおいても、上記の観点というの付いてまわるものであると思う。
Strutsからフレームワークとは何かというポイントを学びながらも
Strutsから脱却しようとする。
Ruby On Railsに憧れながらも
独自思想を打ち出していく。

ここ最近のフレームワークはそういう雰囲気を持っている。


番外でまとめたところ（雑なまとめですいません）のクラスタ
というのは間違いなく、今後普及し、影響を与えていくだろう。

ただ、SIビジネスにおいては、そこの部分が取り入れられるのは5年10年は先の話な気がする。
なんせ、いまだにStrutsが現役なところも多いし、
「仕事のノウハウとしてのStruts」という共通理解的な部分も存在しているように思う。
保守、運用、システム移行など色々めんどくさいのが現状で、
そこからのパラダイムシフト的なものは当面先になるよね、やっぱり。


Javaフレームワークすべてを利用し、把握することはなかなか学習コスト的に厳しい。
しかし、全体構造のマクロ的な把握は、業務においても個人的な利用においても
重要だと思う。新技術が増えて行くからこそ、歴史は大事だと思うのです。