デザインパターンを利用したDBアクセスの実装：JavaのDBアクセスを極める（5）（1/3 ページ）
Webシステムが主流となり、データベース・アプリケーションはJavaやC#といったオブジェクト指向言語で開発することが多くなった。しかし、データベース設計はオブジェクト指向モデルとうまくかみ合わず、データモデル設計に苦労するエンジニアは少なくない。本連載は、オブジェクト指向モデルとデータベースモデルのインピーダンスミスマッチに対応するテクニックを紹介する。（編集局）
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
はじめに
本連載の第2回「O／Rマッピングで失敗しない分析・設計のポイント」では、レイヤごとの責任範囲の明確化と各レイヤ間の依存を少なくする分析・設計のポイントについて解説を行いました。ビジネスロジック・レイヤとデータベース・レイヤを切り分け、レイヤ間を疎結合の状態にすることで、互いのミスマッチを吸収していく手法を理解できたと思います。それでは、実際にどのような手段を用いて実装していけばよいのでしょうか？
本稿では第1回「JavaとDBのデータモデルはナゼすれ違う？」で一般的な疑問として挙げられた以下について、実装例を基に解説をしていきます。
- ビジネスロジック・レイヤとデータベース・レイヤとに分割したが、どうすればレイヤ間に依存しないインターフェイスを実装できるのだろうか。また、データベース・アクセス処理における実装パターンとして要件に合った最適なパターンがありそうだが、ポイントは何だろうか。
図1 今回の解説範囲実装上の問題点と解決策
Javaからリレーショナル・データベース・アクセスを行う場合にはJDBCなどを利用すると思いますが、Javaではエンティティ・オブジェクト、RDBではエンティティ・リレーショナルとしてデータモデルを扱うために、データ属性の違いや、RDBの製品の違いといった環境的な差異により、以下のような問題が発生します。
| 問題点 | 内容 |
|---|---|
| 複雑な永続化処理 | 更新処理の中でさらに別のテーブルを更新するような複雑な永続化処理になってしまう |
| 業務トランザクション制御の複雑化 | 1つの業務処理にて更新を行う場合に複数のクラスに更新処理がまたがり、業務トランザクションの実装が複雑になってしまう |
| ビジネスロジック上でのデータ変換処理の多発 | Java側とRDB側でデータの属性（型やけた数）に違いがある場合、ビジネスロジック上でデータ変換処理が多く発生してしまう |
| メンテナビリティの低下 | 1つのクラス内で複数のテーブルを更新するような作りになっていると、テーブルの変更などがあった場合のメンテナビリティが低くなる |
| データベース変更時に広範囲の修正が必要 | データベースを変更した場合に、SQL方言による依存の問題が発生し、ロジックの修正が広範囲にわたってしまう |
| 表1 実装で発生する問題 | |
JDBCはJavaから直接使用できるAPIのため、実際にプログラムを実装しているときには何となく作りにくいといった漠然としたイメージは持っても、その原因が両者の間にあるミスマッチから発生しているとは気付きにくいものです。しかしこれらの問題をきちんと解決しておかないと、予期しないデータ不整合が発生したり、無駄なロジックの多いメンテナンス性の悪いシステムになってしまいます。
開発する際にはJavaとJDBCを利用したリレーショナル・データの操作にはミスマッチがあるという認識を持ち、問題が表面化しないような工夫をして回避させていく必要があります。具体的には第2回「O／Rマッピングで失敗しない分析・設計のポイント」で解説したように、ビジネスロジック・レイヤとデータベースアクセス・レイヤでそれぞれの責任範囲を明確化し、レイヤ間の依存を少なくする実装をしていくことになります。以降では、それぞれのポイントごとに適用するパターンと実装方法について解説します。（次ページに続く）
Point
- JavaからJDBCを利用しリレーショナル・データの操作を行う場合、互いの扱うデータ属性の違いに伴うさまざまな問題が発生する。
- JDBCはJavaから直接アクセス可能なAPIであるため、ミスマッチに気付きにくい。
- ミスマッチに気付かないまま実装すると、メンテナンス性の悪いシステムになってしまう。
- 問題を解決するには、レイヤごとの責任範囲を明確化し、レイヤ間の依存を少なくする。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。