ケース別のメリット解説（3）
問題4：データベースのテーブル変更
データベースのテーブル定義はシステム設計作業の中で最も重要なものです。ところが開発段階になってもテーブルの仕様が安定しないシステムもよくあります。その場合以下のようなことが発生します。
SE A：テーブルの変更があったようです。テスト用のデータベースも更新されていますね。
SE B：実行するとエラーが発生します。エンティティクラスにあるカラムがデータベースのテーブルから消えているようですね。
SE A：SVNから最新のエンティティクラスのソースを取得すれば出なくなるんじゃないですか ?
SE B：まだエンティティクラスは更新されていませんね……。
SE A：問い合わせたら、エンティティクラスの作成担当が今日休みだそうで、更新は明日になるそうです。
この事例だとデータベースの仕様を管理しているチームに問題があるのは明らかなのですが、テーブルの仕様を変更する手間が多いことも問題でしょう。
多くの場合、「テーブルの構造を変更するためのSQLを作成し適用」「テストデータがあるならそのデータを適切に修正」「作成されたテーブルからORMのツールを使いエンティティクラスのJavaソースを作成する」という手順で行います。それぞれ、「使用しているRDBMSのSQLを把握している技術者」「開発中のシステムの仕様を把握している技術者」「ORMのツールの使い方を知っている技術者」が必要になります。
テーブルの仕様が頻繁に変わるシステムは、それを集中管理するチームの負荷が大きいものになります。そのため、ミスも含めデータベースとエンティティクラスの不整合は思った以上に発生し、作業が止まる原因となります。
このようなことが続くと、共有しているテストデータベースの使用をあきらめ、ローカルPCにデータベースを構築するような対策も考えられます。しかし、これにも開発用PCの負荷が増大するという問題があります。さらに、都合の良いタイミングで共有データベースに適用されたデータベースの変更を取り込む必要があり、それなりのスキルが必要になります。
dataforms.jarは独自のデータアクセスクラス群と開発ツールで、この問題を軽減しています。
dataforms.jarは、Javaのクラスでテーブルの構造を定義します。［開発ツール／テーブル管理］を使うと、このJavaのクラスからデータベース上にテーブルを作成することができます。テーブルの構造を変更する場合は、まずJavaのテーブルクラスを変更し、その後［開発ツール／テーブル管理］でテーブル構造の更新を行うだけで、テーブル構造を変更することができます。この場合、すでに記録されていたデータも可能な限り保持されます。そのためテーブル構造が頻繁に更新されても、それほど負荷がかからずに開発が継続できます。
また、運用中のシステムでテーブル変更が伴うバージョンアップを行う場合、これまでは非常に神経を使う作業になっていました。しかし、dataforms.jarで作られたシステムは、更新されたwarファイルをデプロイし、［開発ツール／テーブル管理］で 変更されたテーブルを更新するだけで完了します。
開発用PCの中に独自のテスト用データベースを作る場合、データベースサーバーソフトが不要なApache Derbyを使うことができます。インストールは簡単でderby.jarをTomcatのlibにコピーするだけです。面倒なRDBMSのインストールは不要です。
dataforms.jarはアプリケーションサーバーが接続しているデータソースの種類に応じて、適切なSQLを発行するように作ってあります。開発用PCではTomcatのJNDIデータソースをApache Derbyに接続するように設定し、開発と単体テストを行います。結合テスト環境のTomcatでは、同じ名前のJNDIデータソースをPostgreSQLに接続するように設定しておきます。この状態の開発環境で作成したwarファイルを、結合テスト環境にデプロイするだけで何事もなく動作します。
現段階ではdataforms.jarはApache DerbyやPostgreSQL、MySQL、Oracleに対応しており、最もテストされているのはApache DerbyとPostgreSQLです。
dataforms.jarは、接続しているデータベースのデータをエクスポートする機能も持っています。エクスポートされたデータはRDBMSに依存しないフォーマットになっており、PostgreSQLからエクスポートしたデータを、Apache Derbyにインポートするなんてことも可能です。この機能を使えば、結合テスト環境のテストデータをローカルの開発環境に持ってくる作業も簡単です。
最後に
dataforms.jarは私の周辺でしか使われていないフレームワークですが、徐々に実績が積まれてきています。今では、私が開発に参加していないプロジェクトも進行しています。そろそろ身内以外の評価も欲しくなってきたところですが、リポジトリのアクセスするのは身内ばかりという状況が続いています。dataforms.jarはネット上に解説記事が一つもないので、そんなものを使おうとする人はほとんどいないのは当然のことです。しょうがないので、自分で書いてみることにしました。今回は利点の紹介のみですが、あわせてdataforms.jar内蔵のドキュメントを参照し、サンプルプログラムの作成を試してみてください。そうすれば、この記事の内容が理解できると思います。
またdataforms.jarのサンプルアプリケーション「dfbbs」を以下のリポジトリに登録してます。
これは簡単な電子掲示板システムで、各記事へのファイル添付をサポートしています。
dataforms.jarは一般のファイル、画像、動画、音声のファイルフィールドクラスを内蔵しており、そのフィールドクラスの動作も確認できるようになっています（動画、音声ファイルのフィールドクラスはHTML5の<video><audio>タグを使用した再生もサポートしています）。
また以下のリポジトリに、簡易Webアプリケーションサーバー（runwar）を登録してあります。
runwarは、組み込みTomcatと組み込みDerbyを1つにまとめたもので、登録したWebアプリケーションを起動後、自動的にデフォルトブラウザを起動し、そのWebアプリケーションのURLをアクセスするようになっています。runwarを使用すると、dataforms.jarで作成されたアプリケーションを、あたかもスタンドアローンアプリケーションのように使うことができます。
こちらからrunwarXXXX.zipをダウンロードし実行すると、dfbbsがサンプルアプリケーションとして動作します。取りあえずdfbbsの動作を確認したい方は、こちらを試してみてください。当然Tomcatが起動していますので、LAN内の別のPCからアクセスし、数人で同じシステムを使うなんてことも可能です。
dataforms.jarで作ったWebアプリケーションをrunwarで実行できるようにしてリリースすれば、Webアプリケーションサーバーやデータベースサーバーの知識がないユーザでも使用を開始することができます。このようなお手軽なWebアプリケーションの需要は結構あると思うのですが、いかがでしょうか？
