JDO APIとLow-Level APIの違いと基本CRUD処理

2010年10月21日(木)
清野 克行

(2)DWRを使ったUI操作と表示

DWRを使うと、HTMLやJavaScriptを使ったWeb UIを作成することなく、プログラム機能を確認できます。

例えば、前ページの図1に示した画面表示では、クラウド上のURLである

をアクセスしています。これに「dwr/」を追加して、

というURLにアクセスすれば、下記のようなDWRのクラス選択画面が表示されます。

図4: DWRクラス選択画面

図4は、DWRクラスの選択画面です。図4の例では、登録されているビーンズ・クラスが1個だけですが、登録されているクラスの数だけ列記されます。

この画面で「msgBean」のリンクをクリックすると、図5の画面表示に変わります。この画面上から、コメント登録や参照用のメソッドを実行して、動作の確認ができます。

図5: DWRデバッグ画面(クリックで拡大)
【コメント情報登録】

図5に示したDWRデバッグ画面には、addMsgとrevMsgという2種類のメソッドが登録されています。このうちaddMsgは、図2のBBS画面から送られてきた書き込み情報をデータ・ストアに永続化するときに使う、Java Beansのメソッドです。図6のようにDWRデバッグ画面から直接登録できます。

図6: DWRデバッグ画面からの直接書き込み(「Execute」クリックで書き込み実行)(クリックで拡大)
【コメント情報参照】

もう1つのrevMsgは、BBS情報を表示するときに使うメソッドです。BigTableに書き込まれている内容を参照しています(図7)。

図7: DWRデバッグ画面で登録済みデータ参照

このように、DWRを使うことによって、Webクライアントの画面を作成することなく、Javaで作成したデータ・ストアの操作プログラムを実行・確認できます。また、必要な場合は、参照内容が実際に登録されたデータと一致しているかどうかの確認も可能です。図8に示したGAEの管理者画面から「Datastore Viewer」を介して確認できます。

図8: Datastore Viewerによる、登録(永続化)データの確認(クリックで拡大)

このように、DWRとGAEの管理者画面を組み合わせることで、サーバー側だけで、プログラムの動作とデータの確認が可能です。データ操作の確認に関しては、ここまで説明した内容だけで、ほとんどの場合は問題ないでしょう。

【ローカル環境での動作・データ確認】

これまで説明してきた動作確認の対象は、アプリケーションをデプロイ(配備)した後のクラウド環境ですが、開発環境であるEclipseの上でも同様の確認が可能です。Eclipse環境でプログラムを実行した後、ブラウザからURLで、

を入力すれば、図5と類似の画面が表示されます。あとは、クラウド環境と同様の手順で、プログラム(メソッド)の動作を確認できます。

3.2. プロジェクト構成の比較

次に、サンプル・プログラムを題材に、JDOとLow-Level APIのプロジェクト構成を比較します。サンプル・プログラムは、JDOによるAPIとLow-Level APIの2種類のAPIを使って、データ・ストアにアクセスします。Eclipse上でのプロジェクト構成は、それぞれ次の通りです。

(1)JDOを使った場合のプロジェクト構成

図9: JDOでのプロジェクト構成(クリックで拡大)

(2)Low-Level APIを使った場合のプロジェクト構成

図10: Low-Level APIでのプロジェクト構成(クリックで拡大)

図9は、JDOを使用した場合のプロジェクト構成です。図10は、Low-Level APIを使用した場合のプロジェクト構成です。

JDO(図9)では、src/jdoajaxの下に、3種類のファイル(msg.java、msgBean.java、PMF.java)があります。これに対して、Low-Level API(図10)では、1種類のファイル(msgBean.java)だけです。つまり、JDOには、Low-Levelにはないファイルが2種類追加されていることになります。

JDOだけが備えているファイルのうち、PMF.javaは、データの永続化用クラスです。もう1つのmsg.javaは、アクセスするデータ・ストアのデータ項目定義、コンストラクタ、アクセサ・メソッドから構成されています。msg.javaの内容は、リスト1の通りです。

3.3. データ・クラスの定義

リスト1: データ・クラス定義(msg.java)

package jdoajax;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class msg {
// 永続化対象プロパティ定義部分(ここから)
	@PrimaryKey
	@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
	private Long uid;
	@Persistent
	private String uname;
	@Persistent
	private String uemail;
	@Persistent
	private String umsg;
	@Persistent
	private String udate;
// 永続化対象プロパティ定義部分(ここまで)

	public msg(String uname, String uemail, String umsg, String udate) {
		this.uname = uname;
		this.uemail = uemail;
		this.umsg = umsg;
		this.udate = udate;
	}
	public Long getId() { return uid;}
	public String getUname() { return uname;}
	public String getUemail() { return uemail;}
	public String getUmsg() { return umsg;}
	public String getUdate() { return udate;}

	public void setUname(String uname) { this.uname = uname;}
	public void setUemail(String uemail) { this.uemail = uemail;}
	public void setUmsg(String umsg) { this.umsg = umsg;}
	public void setUdate(String udate) { this.udate = udate;}
}

リスト1の中の、永続化対象プロパティ定義部分は、RDBにおけるスキーマ定義に類似しています。このような定義があることにより、初めてBigTableなどのKVSを扱うプログラマは「KVSもRDBとあまり違わない」という誤解を持ってしまう場合があるようです。

KVSの場合も、あらかじめデータを格納するkind(≒テーブル)のデータ定義を行ってから、READ/WRITEなどでデータにアクセスします。こうした手順を踏むことが理由となり、「RDBと似ている」という印象を受けることになります。

しかし、このサンプルにLow-Level APIを適用することによって「KVSはRDBとは全く異なっている」ことを実感できます。図10に示したLow-Level APIのプロジェクト構成には、リスト1のようなデータ・クラス定義ファイルはありません。分散KVSのBigTableは、スキーマレスなデータ・ストアであり、永続化用のデータ(プロパティ)項目をあらかじめ定義しておく必要がないのです。

有限会社サイバースペース
慶應義塾大学工学部電気科卒。日本IBM、日本HPなどにおいて、製造装置業を中心とした業務系/基幹業務系システムのSE/マーケティングや、3階層C/Sアーキテクチャによる社内業務システム開発などに携わる。現在は、Ajax/Web 2.0関連のセミナー講師/コンサルティング、書籍執筆などを行っている。情報処理学会会員。http://www.at21.net/

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています