この特集のトップページへ
＞ Chapter 6：ビジネスロジックの設計

6.3.5　在庫の処理
●入出庫予定の一覧取得

○テーブルの連結
　ところで，先に示したGetRecordsメソッドで，条件に合致するレコードを閉じたADODB.Recordsetオブジェクトとして返す場合，在庫情報テーブルをそのまま返したので，扱いやすいとはいえない。在庫情報テーブルをそのまま返した場合，つまり“SELECT * FROM 在庫情報”（実際にはさらに，メソッドの引数として渡された条件から生成される絞り込みのWHERE条件式が加わる。また，“*”の部分にフィールド名をきちんと列挙する）というSELECT文を実行して得られた結果は，Fig.6-68のようになる。

Fig.6-68　在庫情報テーブルをそのまま取得したもの
fig6_68

　得られた結果には，入庫情報や出庫情報が含まれている。通常は，これをユーザーに表形式で表示するというユーザーインタフェースをプレゼンテーション層が提供することになるだろう。しかし，Fig.6-68の形式では該当する製品が製品番号で表示されているため，ユーザーにとってわかりやすいものとはいえない。やはりユーザーに表示するためには，製品番号だけでなく製品名も表示したほうがよいだろう。

　そのためには，“SELECT * FROM 在庫情報”という在庫情報テーブルのみから得られた結果を返すのではなく，“SELECT 在庫情報.*, 製品情報.PRODUCTNAME FROM 在庫情報, 製品情報 WHERE 在庫情報.PRODUCTID = 製品情報.ID”というSELECT文を発行し，在庫情報テーブルと製品情報テーブルの2つを組み合わせた結果を返すようにすればよい（Fig.6-69）。

Fig.6-69　在庫情報テーブルと製品情報テーブルの2つのテーブルを組み合わせた結果を返したもの
fig6_69

　このようにすれば，取得したデータをそのままプレゼンテーション層側でユーザーに対して表形式で表示しても，わかりやすいものとなる。

　2つのテーブルの結合は，データオブジェクトで実行してもよいし，データオブジェクトの上位層となるビジネスロジック層で実行してもよい。ビジネスロジック層で結合を処理する場合には，製品情報を取得するデータオブジェクトと在庫情報を取得するデータオブジェクトをそれぞれ使い，結果をマージして返すことになるだろう（Fig.6-70）。

Fig.6-70　ビジネスロジック層で結合する場合
fig6_70

　しかし，この方法だと，結合処理がかなりやっかいになり，パフォーマンスも低下する。そのため，このサンプルではこの方法は採用せず，結合した形式のレコード（Fig.6-69）をデータオブジェクトで返し，ビジネスロジック層はその結果をプレゼンテーション層に中継するだけとする（Fig.6-71）。

Fig.6-71　データオブジェクト層で結合する場合
fig6_71

　この場合，当然ながらデータオブジェクトとデータベースは1対1で対応しなくなる。しかし，データオブジェクトとデータベースは必ずしも1対1で対応しなければならないという決まりはないので，気にすることはない。

　いずれにせよ，ビジネスロジック層からFig.6-68に示した形式でデータを返し，プレゼンテーション側でテーブルを結合処理するというのは避けたほうがよい。実際に，Fig.6-68に示した形式のデータを受け取ったプレゼンテーション層は，すでに実装したBusiness.ProductコンポーネントのGetProductメソッド（List 6-59）を呼び出すことで，製品番号から製品名を取得することはできる。しかし，プレゼンテーション層は，あくまでもユーザーとの入出力をサポートするのが目的であり，複雑なデータの加工を担当させるべきではない。プレゼンテーション層が処理しやすい形式にデータを加工して受け渡すのは，ビジネスロジック層の仕事である。

　もし，プレゼンテーション層で複雑なデータ加工処理をしようとすると，パフォーマンスが低下するばかりか，複数の種類のユーザーインタフェースを提供する場合（たとえば，Visual Basicによる実行ファイル形式とWebからの利用の2つのユーザーインタフェースを提供する場合など）に，それぞれのユーザーインタフェースに同じようなデータ加工処理を実装しなければならない羽目になる。これでは，N階層に分けた意味が薄れてしまう。よって，ビジネスロジック層がプレゼンテーション層に対してできるだけ扱いやすいデータ形式で返すことが望まれる。

prevpg.gif Chapter 6　49/92 nextpg.gif