はじめに
私は30年以上のシステム開発経験を持つエンジニアです。アセンブラやCで大規模なシステムを作った経験もありますが、最近はJavaなどでWebアプリケーションを作ることが多くなっています。また、プロジェクトの規模も変わってきており、以前は大手のシステム開発に参加することもありましたが、最近は中小のシステムを担当することが増えています。その規模のプロジェクトでは、私にプロジェクトリーダーが回ってくることも多くなりました。そのリーダーの役割として重要なことの1つが、フレームワークの選定です。
Webアプリケーションの場合、「M（Model）」「V（View）」「C（Controller）」モデルに準拠した作りが良いとされており、Javaには「M」「V」「C」にそれぞれ複数のフレームワークが存在しています。例えば、画面の表示を担当するライブラリには、便利なカスタムタグが提供されています。また、ビジネスロジックをサービスとして提供するものや、データベースの記録内容を自動的にJavaクラスのプロパティに展開してくれるものもあります。大規模なプロジェクトになるとフレームワーク構築チームが存在し、「M」「V」「C」それぞれのライブラリを組み合わせ、さらに独自に機能を追加した状態でフレームワークが提供されるケースもあります。
しかし、私はこのアプローチをとらず、独自のフレームワーク構築を始めてしまいました。なぜなら、既存のJavaフレームワークは中小のシステムを手っ取り早く作るのに向かないという印象を持っていたためです。最初は個人的に作ったアプリケーションで使うために用意したものでしたが、今ではお客さまから受注したシステムでも使用し、いくつかのアプリケーションが運用されています。
当然のことですが、フレームワークというものは、簡単に利点を理解できるものではありません。そこで今回の記事では、dataforms.jarが既存のフレームワークと比較してどのような利点があるのか、ケース別に紹介します。
Java Webアプリケーションフレームワークdataforms.jarはこちらで入手することができます。
このリポジトリのREADME.mdにEclipseのプロジェクト作成手順が簡単に書いてあります。これだけではわからないという方は、ドキュメントを参照してください。
このWebサイトでは、ドキュメントに記載された手順で作成したサンプルアプリケーションが動作しています。アプリケーションの開発環境を構築すれば、同様にドキュメントの参照ができるようになります。
対象読者
この記事を読むのに必要な知識は以下の通りです。
- Java
- JavaScript
- jQuery、jQuery UI
- HTML、CSS
- SQL
必要な環境
dataforms.jarを使用した開発では、以下のものを使用しています。
- JDK1.8
- Eclipse 4.5以上
- Tomcat 7以上
ケース別のメリット解説（1）
ここからは既存のフレームワークで体験した問題を挙げて、どのように対策したのかということを説明していきます。
問題1：フレームワークの大規模化
大きなプロジェクトに参加すると、大抵以下のような会話が交わされます。
SE A：SVNにプロジェクトが登録されたようです、各自チェックアウトして、担当の作業を始めてください。
SE B：なんか取得にやたら時間がかかるなあ……。
SE C：やっと取得が終わったからビルドしてみよう……ビルドに3分、サーバー起動に2分だと？
SE B：WEB-INF/lib見たらjarファイルが200くらいあるんですけど……。
SE A：フレームワークがバージョンアップしたので、こんな機能が使えるようになります。SVNから取得してください。
SE B：なんだかさらに、ビルドが遅くなったぞ。
SE C：jarファイルがさらに増えたようですね。
これは、「M」「V」「C」それぞれのフレームワークが独自に作成されたもので、個々が巨大化したために発生している問題だと思います。それぞれのフレームワークが依存するライブラリの数も多くなるため、ビルドの速度は低下し、出来上がる*.warファイルが巨大になります。そのためデプロイにも時間がかかるようになります。
システムのデバッグ時にはソース修正→ビルド→デプロイ→テストを散々繰り返すことになります。そして、ビルド＋デプロイにかかる時間が長くなればなるほど開発効率は落ち、プロジェクトがデスマーチになる確率が上がっていきます。
さらに、開発が終わって運用テストの段階になると、今度はこのアプリケーションを十分な性能で動かすため、サーバーの増強が必要になります。大手企業であれば、このようなシステムの開発運用の経費を出すことも可能でしょうが、中小企業向けのシステムでは、なかなか対応できないと思います。
フレームワークの名前を「dataforms.jar」としたのは、フレームワークの全てが1つのjarファイルの中に入っていることに由来しています。jarファイルのサイズは今のところ8MBくらいです。この中に、独自に実装された「M」「V」「C」それぞれの機能と、さらにユーザ管理、ログインなどのアプリケーションの基本機能、開発ツールとそのドキュメントも入っています。依存しているライブラリはApache Commonsのいくつかと、Log4J、JSONIC、POI、jQuery、jQuery UIくらいです。dataforms.jarを利用して作成したシステム（Javaソースファイルの実行ステップ数 約17000）を、Eclipse上でTomcatを起動した状態でクリーンビルドし、オートデプロイが完了するまでの時間は20数秒でした。
問題2：学習コスト
私は以前大手企業の規模が大きなプロジェクトを渡り歩いていました。そのようなプロジェクトには、情報システム部門が選定したフレームワークが存在するので、それを使って構築を進めていく必要があります。すると、毎回以下のような会話になります。
SE A：今回のフレームワークはA、B、Cの組み合わせで、独自の便利なカスタムタグが提供されるので開発は簡単ですよ。
SE B：ほう、なかなか使いやすそうですね。
半年後……
SE A：今回のフレームワークはD、E、Cの組み合わせです。今回は各種タグのカスタムアトリビュートでいろいろできますよ。
SE B：なかなか便利そうですが、同じJavaの開発なのに結構違いますね。また新しいことを覚えないと……。
SE B：データベースの接続を障害テスト用のものに切り替えたいと思うのですが、接続情報はどのファイルに書いてありますか ?
SE A：ちょっとわからないので、フレームワークチームに問い合わせます。
大手の情報システム部門としては、社内で稼働するシステムの構造を統一したいと思うのは当然のことです。そうすれば各種ノウハウが蓄積され、システムの運用管理も楽になります。そのような部門の方々は、新しいカスタムタグや、特殊なXMLの設定ファイルを覚えると、長期にわたりそのノウハウを使うことができます。
しかし、われわれのような社外のエンジニアは、大きなプロジェクトに参加するたびに、異なるフレームワークを学習しなければならなくなります。つまりある時はカスタムタグを覚え、ある時はカスタムアトリビュートを覚え、ある時はXMLの設定ファイルの書き方を新たに覚えなければいけません。
このように、さまざまなフレームワークの開発を経験した結果、それらの学習コストの高さを感じるようになりました。
JavaでWebアプリケーションを作ったことのある技術者であれば、JavaやHTML、CSS、JavaScriptの知識を持っていると思います。SQLに関しても、RDBMSごとの方言を除けば、基本的な部分は理解しているはずです。また、いくつかのアプリケーションサーバーの設定ファイルがある場所と編集方法（web.xmlやTomcatであればserver.xmlやcontext.xmlのXMLスキーマ）も把握しているでしょう。Java Webアプリケーションの黎明期を経験しているエンジニアからすれば、この知識があれば十分アプリケーションが作れると思っています。そこでdataforms.jarは、これ以上の文法やXMLスキーマを新たに覚えなくても良いように設計しました。この観点からdataforms.jarの特徴をまとめると以下のようになります。
Viewは単純なHTMLで構築し、カスタムタグやカスタムアトリビュートは使用しない
Viewを構築するのに必要な知識はHTMLとCSSくらいになります
Javaのクラスとそれに対応したJavaScriptのクラスが連携して動作する構造になっている
Javaの部分は単純なPOJOで組まれたライブラリです。またJavaScript側にもJavaと同じ構造のクラス階層が存在し、それぞれが連携して動作する構造になっています。
データベースの構造や問い合わせもJavaで定義する
データベースのテーブル構造や問い合わせ等は全てJavaのクラスで記述します。SQLでどのようなことができるかという知識は必要になりますが、それらの機能は全てJavaで記述します。SQLの方言はdataforms.jarで吸収するため、RDBMSごとの違いを意識することなく開発が可能になります。
ソースを自動生成する機能を持つ
dataforms.jarには各種開発ツールが含まれており、取りあえず動作するソースコードを生成することができます。また、データベースのテーブルを定義するJavaソースも開発ツールで作成することができ、そのテーブルを検索したり編集したりするページも、開発ツールで生成して動作させることができます。
新しいフレームワークを理解するためには、そのサンプルコードは必要不可欠なものです。自動生成されたコードもサンプルとして読みやすいものになっています。そのコードを理解できれば、スムーズに独自機能の追加作業に入ることができます。
アプリケーションの各種設定はweb.xmlに記述する
dataforms.jarのプロジェクトでXMLを編集するのは、web.xml中のdataforms.jarの設定とconext.xmlのJDNIデータソースの設定くらいです。そのため「この設定はどのファイルで行えるの？」などと迷うことがありません。
