Java EEにMVCはなぜ必要なのか
この記事は?
Java EE Advent Calendar 2017の22日目です。
6日目の@khasunumaさんの記事「MVC のこれまでとこれから」で、MVCがこれまで辿ってきた経緯が解説されていました。
僕は個人的にMVCを待ち望んでいました。早い段階からブログを書いたり、JJUG CCCで発表したりもしていました。今でも、「MVC 1.0」でググると多くは僕の記事がヒットします。
蓮沼さんは上記の記事では、「MVCはあるに越したことはないが必須ではない」というご意見でしたが、僕はこの記事のタイトル通り「MVCは必要」という意見です。
世の中には色んな意見があっていいと思いますので、ここで論じてみたいと思います。少しでも参考になれば幸いです。
意見1: Java開発者の多くはアクションベースフレームワークに慣れている
JavaでWebアプリケーションを作る場合のフレームワークといえば、昔のものになりますが、やはりStruts 1.xやSeasar2(正確にはS2StrutsやSAStruts)が多勢を占めるでしょう。これらはすべて、HTTPのリクエスト・レスポンスのやり取りを記述する「アクションベースフレームワーク」に分類されます。他のフレームワークも、ほとんどがアクションベースでしょう。
それに対して、JSFは「コンポーネントベースフレームワーク」です。画面のパーツやイベント(ボタン押下など)に着目して実装します。JSF以外にもコンポーネントベースフレームワークは存在しますが、Javaでは少数派です。また、Swing・JavaFX・AndroidなどによるGUIプログラミングを経験したことがある人は、Webアプリをアクションベースで作った経験がある人に比べれば少数でしょう。
つまり、多くの人はアクションベースに慣れており、コンポーネントベースに慣れている人はあまり多くありません。(あくまで僕の実感ベースですが)このような状況下で、特に大人数の開発者が必要なプロジェクトでは、「よし、コンポーネントベースのJSFを採用しよう」とはならないのではないでしょうか。
もちろん、サーバーベンダーのサポートを受けたいからJava EE標準で作りたいという場合は、選択肢がJSFしかありませんので、JSFが採用されるでしょう。しかし、もしJava EE標準のアクションベースMVCも選択肢として存在するなら、JSFではなくMVCの方が採用されるのではないでしょうか。
意見2: すべてのWebアプリがフルJavaScriptで画面を作られる訳ではない
確かに、いまJavaScriptでUIを構築することが増えています。Angular・React・Vueなど、JavaScriptフレームワークの進化はとても速いです。もちろん、画面をすべてJavaScriptとピュアなHTMLで書くことも多いでしょう。
しかし、すべてのWebアプリがそうではないと思います。従来のように、サーバーサイドでHTMLを出力し、JavaScriptを補助的に使うようなアプリもまだまだ存在するでしょう。
JSFは、この用途には向いていません。画面上にJavaScriptで処理を記述すると、JSFが内部的に使っているJavaScriptコードと競合したり、画面上で処理した結果がサーバー側で保持しているコンポーネントツリーと矛盾したりして、うまく動かないことがあるからです。
なので、シンプルに「サーバーサイドでHTMLを出力するだけ」のフレームワークが求められます。それがMVCなのです。
これからMVCはどうなる?
蓮沼さんのブログにもある通り、今もMVCは仕様策定プロセスが進んでいます。現スペックリードの1人であるIvar GrmstadさんはEE4Jでも中心人物であり、今後はEE4Jの傘下で積極的な活動が続くでしょう。実際に、つい先日(12月18日)、Public Reviewという重要なバージョンがリリースされました!
前のバージョンであるEarly Draft Review 2は2015年11月であり、2年以上ぶりのリリースになります。とても感慨深いです。
正式リリースがいつになるかは現時点では不明です。完全に僕の予想ですが、早くて2018年、遅くとも2019年前半には正式リリースになるのではないでしょうか。
MVCに限らず、Java EEはこれからどのように仕様策定プロセスをすすめるのかなど、EE4Jで検討中の事項が多いです。まだしばらく待つ必要がありますが、期待して待ちましょう。