|
||||||||||
| 前のページ 1 2 3 | ||||||||||
| DOA活用事例〜B社の例(永続化されたドメインモデル) | ||||||||||
|
概要は次の表4の通りです。
表4:B社の概要 ER図とデータアクセスフレームワークの関係は、図6の通りです。 論理エンティティと物理テーブルが1:1となっている箇所、および正規化されたテーブル群を1つのビジネスエンティティに集約し、再度パーシスタンスで1テーブル単位に分割している箇所がポイントです。 また、永続化を実現したオブジェクト指向的な設計のため、アプリケーション開発者はビジネスエンティティを通して物理テーブルを意識せず、通常のJavaクラスとまったく同等に扱うことができます。 データアクセスフレームワークの実装は、以下の通りです。 BusinessFacadeを持つことにより、アプリケーション開発者は永続化を意識せず、ビジネスエンティティを操作することができます。 |
||||||||||
| B社プロジェクト担当者の独白 | ||||||||||
|
実際にB社プロジェクトを担当した技術者による、開発時のポイントを紹介しておきます。 |
||||||||||
| プロジェクト中の設計書 | ||||||||||
|
専任のDA(Data Architect:データアーキテクト)が設計したER図を、アーキテクトが概念クラス図に作成していきます。アーキテクトは概念クラス図とER図をマッピングし、より実装を意識した論理クラス図へと詳細化します。 担当者はこのプロジェクトでBusinessFacade以降に関わり、ER図・論理クラス図・シーケンス図の3つをベースに、設計書を見ながら、実装を行っていきました。なお、ModelMapperについては、マッピング自動化ツールを使わずに実装しています。 このプロジェクトでは、通常のERより完全に正規化されたテーブル構造を用いていたため、Javaプログラミング以外にSQLに精通している必要がありました。このようなケースで論理クラス図およびER図からクラスのインスタンスを作るには、どんなSQLで値を取得/生成するのかを考える必要があります。 |
||||||||||
| プロジェクト中の注意点 | ||||||||||
|
特に注意すべき点はNullの取り扱いです。実装されたテーブルレイアウトは、すべての項目が「Not Null」となっています。ただし、クラスをインスタンス化した状態では、フィールドに「Null」が設定されている場合があり得ます。 インスタンスのNullへの対処を怠ると、当然ながらNullPointerExceptionで、アプリケーションが異常終了してしまいます。そこで、どこのレイヤでこのNullをフォローするかを検討する必要がありました。このケースでは、アーキテクトや他のレイヤを実装した開発者の意見を聞きながら、実装を進めていきました。 |
||||||||||
| プロジェクトを振り返って | ||||||||||
|
設計段階での未決事項が、実装段階で顕在化する形になり、余計なコストがかかりました。設計段階で可能な限り明確な分析を行い、未決事項を明らかにしておくことが重要と考えられます。 Nullの取り扱いについては、実際の現場では実装段階に至るまで明確にならないこともある得ます。アプリケーション内で空項目の扱いをレイヤ単位で切り分けるルール作りが必要です。なお、空項目には「未定」と「不定」の2つの視点があります。未定とは、「他のデータ項目と一緒に値が決まらないことがある」という空値であり、不定とは「値を定めないことが何らかの意味を持つ」という空値になります。 また、トランザクションの取り扱いについて、実装段階で柔軟にあつかえるDBコネクションが必要です。また、静的な設計書では表現しきれないトランザクション設計の明文化も必要となります。 |
||||||||||
| まとめ | ||||||||||
|
正規化されたRDBとJavaによるデータアクセスは、標準とされる解決方法がないのが現状です。 最近は、HibernateやS2DaoのようなオープンソースのO/Rマッピングフレームワークを紹介する記事が多いため、それらは他の記事に譲り、今回は筆者が経験した独自実装のO/Rマッピングフレームワークを紹介しました。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||




