DTO(Data Transfer Object)の必要性

3階層クライアント/サーバ型システムでは、物理的に3つの層に分かれているため、層と層の間は通信してデータをやり取りする。一般にデータベースとアプリケーションサーバ間は、ADO.NETの規定の方法で通信し、アプリケーションサーバとクライアントは、Webサービスや.NET Remotingなどの技術を使って通信する。後者の通信には、データの受け渡し専用の入れ物を用意し、このオブジェクトを使ってデータをやり取りしたほうが、次の述べる2点で都合がよいと筆者は思う。
このオブジェクトをDTO(Data Transfer Object)という。サンプルコードは末尾に示す。


第一は、パフォーマンスで有利な点である。アプリケーションサーバとクライアント間は主としてLANであるが、もっともボトルネックになりやすいところである。この間でやり取りするデータ量はできるだけ少なくし、また通信の回数を減らしてパフォーマンスを下げないことが、リッチクライアント型システムの成否を握っているといっても過言ではないと筆者は考える。

DTOを使うことによって、アプリケーションサーバとクライアント間の通信を1つの処理に付き1回にすることができる。クライアントからアプリケーションサーバに要求する処理内容をこのDTOにすべて詰め込み、アプリケーションサーバは処理結果の応答をDTOに詰め込みクライアントに返す。こうすることで、クライアントからアプリケーションサーバへの呼び出しは1往復で済むのである。

一般的な業務システムの画面を例に説明する。業務画面であれば、ひとつの画面にコンボボックスやリストボックス、データグリッドビューなどがいくつか配置されており、画面の初期化時にマスターデータ(商品カテゴリや商品名や顧客名など)をこれらのコントロールにセットする。コントロールにセットするマスターデータは、内容が異なれば異なるテーブルに保存されているはずので、異なるDataTable(またはDataSet)で取得することになる。その際、クライアントからアプリケーションサーバへコントロールごとにデータ取得を依頼することは、ボトルネックのネットワークを何往復も通信することになり、パフォーマンスも悪くなる。

 そこで、クライアントからはDTOに必要な情報のキーだけを保存してアプリケーションサーバに依頼する。アプリケーションサーバはすべての要求の結果を、DTOに詰め込んで返す。結局、クライアントとアプリケーションサーバは1回だけの要求と応答で処理が完了し効率的である。


 第二はのメリットはクライアント側で、アプリケーションサーバ側のエラーや例外の発生を検知できることである。
 アプリケーションサーバとクライアントは、それぞれの筐体で起動している異なるアプリケーションであるから、アプリケーションサーバ側で発生した例外は、クライアント側のtry~catch句では捕捉できない。なので、アプリケーションサーバで発生した例外やエラーは、何らかの仕組みでクライアントに通知する必要がある。

 そこで、DTOに、アプリケーションサーバ側で発生した例外やエラーの内容を記録する仕掛けを組み込んでおき、クライアントはどこでどんな現象が発生したか知ることができるのである。

最後に、DTOクラスのサンプルコードを紹介する。サンプルは要求(上り用)と応答(下り用)に分かれている。


トラックバック

トラックバックURL:
http://www.apricot-jp.com/cgi/mt/mt-tb.cgi/255

関連情報

Copyright(C) 2007 アーキテクト360 Allrights reserved.