 |
|
|
| 前のページ 1 2 3 次のページ
|
|
| 一般的な解決策
|
では、DOAとオブジェクト指向のデータアクセスでの問題点をどのように解決していけばよいのでしょうか。それには次のような手法があると考えられます。
|
| 実装技術 |
表2は、データアクセス手法を比較したものです。
| 手法 |
実装技術 |
メリット |
デメリット |
| SQL |
JDBC、SQLJ |
緻密な制御が可能 |
生産性・保守性の悪さ |
| O/R マッピング |
EJB (Entity Bean) |
コンテナに永続化を委譲可能 |
本質的でないコーディングが多い
制限・制約が多い（テストを含む） |
| O/R マッピングフレームワーク（Hibernate、iBATISなど） |
フレームワークでRDB をそのまま永続化可能 |
設定ファイルが多く・散在する
コンパイラでチェック不可
|
| 永続化 |
OODB（Cacheなど） |
オブジェクトをそのまま永続化可能 |
製品・技術者の不足 |
表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の通りです。
| データ正規化 |
ほどほど
※アプリケーションの使い勝手を重視 |
| O/R マッピング |
自作のフレームワーク（JDBCラッパー） |
| DAOパターン |
| テーブルモジュール |
| テーブルデータゲートウェイ |
| 特徴 |
論理ER図をそのままドメインモデルとして実装 |
| 論理ER図と物理テーブルは異なる |
| 論理ER図よりJava コードを自動生成 |
表3：A社の概要
ER図とデータアクセスフレームワークの関係は、以下の通りです。
図3：A社メタモデル （画像をクリックすると別ウィンドウに拡大図を表示します）
論理エンティティとドメインモデルが、1:1となっている箇所がポイントです。この例では論理エンティティをそのままドメインモデルとして実装しており、アプリケーション開発者は物理テーブルを意識する必要がありません。
またアプリケーション開発者が、コネクション管理・楽観排他・論理削除・監査証跡などをデータアクセスフレームワークに任せて意識する必要がないように工夫をしています。ただし、シンプルなJDBCラッパーのため、永続化やドメインモデル間の参照は、サポートしていません。
データアクセスフレームワークの実装は、以下の通りです。
図4：A社クラス図 （画像をクリックすると別ウィンドウに拡大図を表示します）
図5：A社シーケンス図 （画像をクリックすると別ウィンドウに拡大図を表示します）
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
システムズ・デザイン株式会社 DOA推進ワークショップ
ビジネス解析方法論であるDOAと、開発プロセス方法論であるRAD、ウォーターフォール、UPなどを現場の最前線で適用している技術者を中心に開設した、sdc独自のワークショップ。PDCAサイクルを回して、さらなる進化と「確かなモデリング∧確かな開発プロセス→いい仕事」の可能性を追求する。
|
|
|
|
|
|
