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(正確にはS2StrutsSAStruts)が多勢を占めるでしょう。これらはすべて、HTTPのリクエスト・レスポンスのやり取りを記述する「アクションベースフレームワーク」に分類されます。他のフレームワークも、ほとんどがアクションベースでしょう。

それに対して、JSFは「コンポーネントベースフレームワーク」です。画面のパーツやイベント(ボタン押下など)に着目して実装します。JSF以外にもコンポーネントベースフレームワークは存在しますが、Javaでは少数派です。また、Swing・JavaFXAndroidなどによる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という重要なバージョンがリリースされました!

www.mvc-spec.org

前のバージョンであるEarly Draft Review 2は2015年11月であり、2年以上ぶりのリリースになります。とても感慨深いです。

正式リリースがいつになるかは現時点では不明です。完全に僕の予想ですが、早くて2018年、遅くとも2019年前半には正式リリースになるのではないでしょうか。

MVCに限らず、Java EEはこれからどのように仕様策定プロセスをすすめるのかなど、EE4Jで検討中の事項が多いです。まだしばらく待つ必要がありますが、期待して待ちましょう。