 |
|||||||||||||||||||
|
|||||||||||||||||||
| 前のページ 1 2 3 次のページ | |||||||||||||||||||
|
|||||||||||||||||||
| 一般的な解決策 | |||||||||||||||||||
|
では、DOAとオブジェクト指向のデータアクセスでの問題点をどのように解決していけばよいのでしょうか。それには次のような手法があると考えられます。 |
|||||||||||||||||||
| 実装技術 | |||||||||||||||||||
|
表2は、データアクセス手法を比較したものです。
表2：データアクセス手法の比較 いずれもすべての事例に当てはまる「決め手」とはなりません。一般的に、小規模案件ではSQL、大中規模ではO/Rマッピングが利用されるケースが多いようです。 オブジェクト指向データベースは、製品が充実していれば、O/Rマッピングのような事柄を考える必要がないため、もっとも優れているといえるでしょう。しかし実際には、製品と技術者がまだまだ不足しているのが現状で、今しばらくはRDBが主流の時代が続くでしょう。 |
|||||||||||||||||||
| 設計技術 | |||||||||||||||||||
|
DAO（Data Access Object）は「J2EEパターン」に登場するパターンですが、「現在Javaでのデータアクセスといえばこれ」というほど、広く利用されています。これは、図1のようにデータアクセスに関する部分をDAOにのみ割り当て、データアクセス処理を抽象化する方法です。  図1：DAOパターン （画像をクリックすると別ウィンドウに拡大図を表示します） これに対して「PofEAAパターン」は、ドメイン層（ビジネスロジック）の責務を中心としたアーキテクチャの実装方法です。PofEAAパターンについてはマーチン・ファウラー氏の「エンタープライズアプリケーションアーキテクチャパターン」に登場しています。  図2：PofEAAパターン （画像をクリックすると別ウィンドウに拡大図を表示します） |
|||||||||||||||||||
| 実例紹介 | |||||||||||||||||||
|
では、実際にDOAを活用した事例についてみていきましょう。ここでは、シンプルなJDBCラッパーを利用したA社と、永続化されたドメインモデルを採用したB社の2つを取り上げます。 |
|||||||||||||||||||
| DOA活用事例〜A社の例（シンプルなJDBCラッパー） | |||||||||||||||||||
|
概要は次の表3の通りです。
表3：A社の概要 ER図とデータアクセスフレームワークの関係は、以下の通りです。  図3：A社メタモデル （画像をクリックすると別ウィンドウに拡大図を表示します） 論理エンティティとドメインモデルが、1:1となっている箇所がポイントです。この例では論理エンティティをそのままドメインモデルとして実装しており、アプリケーション開発者は物理テーブルを意識する必要がありません。 またアプリケーション開発者が、コネクション管理・楽観排他・論理削除・監査証跡などをデータアクセスフレームワークに任せて意識する必要がないように工夫をしています。ただし、シンプルなJDBCラッパーのため、永続化やドメインモデル間の参照は、サポートしていません。 データアクセスフレームワークの実装は、以下の通りです。  図4：A社クラス図 （画像をクリックすると別ウィンドウに拡大図を表示します）  図5：A社シーケンス図 （画像をクリックすると別ウィンドウに拡大図を表示します） |
|||||||||||||||||||
|
前のページ 1 2 3 次のページ |
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|||||||||||||||||||
-
-
連載
