連載

アプリケーション・アーキテクチャ設計入門

第3回 論理アーキテクチャを構成するコンポーネントの設計(ビジネス/データ層編)

日本ユニシス 猪股 健太郎
2003/10/25

Page1 Page2 Page3

データ層

■データアクセス・ロジック・コンポーネント

 「データアクセス・ロジック・コンポーネント」は、データソースに固有のデータアクセス・ロジックを抽象化して、呼び出し元のコンポーネントにデータ・ストアへのシンプルなアクセス手段を提供するコンポーネントだ。データアクセス・ロジックをカプセル化し、1カ所で集中管理することで、保守・拡張が容易になる。

特徴

  • 呼び出しをまたいで状態を保持しない

  • 1つのデータアクセス・ロジック・コンポーネントは1つのデータソースだけにアクセスする

  • ほかのデータアクセス・ロジック・コンポーネントを呼び出さない

  • 複数トランザクションを開始しない

 

役割

  • エンティティに対する操作として、一般的にCRUD(Create、Refer、Update、Delete)のメソッドを提供する

  • 主となるテーブルに作用するだけでなく、関連テーブルの操作も実行する

  • 複数のテーブルを連結し、読み出し専用でデータを取得する

  • データを更新して再取得する

  • エンティティのスキーマやクエリのパラメータなどのメタデータを返す

  • ユーザー・インターフェイスのために、結果セットをページングする

 これらに加えて、楽観的ロックのカプセル化や、トランザクションに関係しないクエリ結果のデータ・キャッシュなどを実現するユーティリティ・コンポーネントを用意しておいて、適宜呼び出すこともする。また、大規模なシステムで、データを複数のサーバに分散させる場合は、データを動的にルーティングする。

 

推奨

  • 必要なデータだけを返す

  • 特定のスキーマからデータアクセスを抽象化するためストアド・プロシージャを使う。ただし、ストアド・プロシージャを使いすぎるとコードの保守性や再利用性が悪くなるため注意する

  • データ操作は可能な限りRDBMSで実行させる

  • Insert、Read、Update、Findなど、よく使われる機能はストアド・プロシージャで実装する

  • すべてのデータアクセス・ロジック・コンポーネントに共通な機能はインターフェイスや基本クラスとして公開する

  • 異なるクライアントに対しても一貫したインターフェイスを設計する。例えば、インターフェイスの設計がビジネス・コンポーネントの実装に依存しないようにする

  • スキーマやカラム名などのメタデータを公開する

  • エンティティの関連を表現するテーブルについては、対応するデータアクセス・ロジック・コンポーネントを作らない。例えば、書籍と著者の関連をTitleAuthorテーブルで表現している場合は、著者テーブルにアクセスするデータアクセス・ロジック・コンポーネントにAddBookメソッドを用意するか、書籍テーブルのデータアクセス・ロジック・コンポーネントにAddAuthorメソッドを用意する

  • データを暗号化して保存するなら、データアクセス・ロジック・コンポーネントが復号化を処理する

  • ビジネス・コンポーネントをエンタープライズ・サービスで実装する場合は、データアクセス・ロジック・コンポーネントもサービス・コンポーネント化する。エンタープライズ・サービスを使っていないか、アプリケーション・ドメインをまたがる呼び出しがないのであれば、サービス・コンポーネントにしなくてもよい

  • トランザクション分離レベルを検討する。パフォーマンスが要求される場合は低いトランザクション分離レベルで動作する特別な操作を用意してもよいが、異なるトランザクション分離レベルを結合させるとデータの一貫性に悪影響を及ぼすので注意する

 多くのデータアクセス・ロジック・コンポーネントが同じデータソースにアクセスするようなアプリケーションでは、データアクセスAPIへのアクセスやコネクションの設定といったロジックがデータアクセス・ロジック・コンポーネントに共通して存在する場合がある。そのような共通的なロジックを局所化させるために、「データアクセス・ヘルパー・コンポーネント」を使うのもよい。

データアクセス・ヘルパー・コンポーネント
データアクセスAPIへのアクセスやコネクションの設定といったデータアクセス・ロジック・コンポーネントに共通するロジックは、データアクセス・ヘルパー・コンポーネントとしてまとめる。

 データアクセス・ヘルパー・コンポーネントは、1つのデータソースに対し1〜2個あればよいだろう。例えば、1つのデータアクセス・ヘルパー・コンポーネントはストアド・プロシージャを呼び出し、もう1つのデータアクセス・ヘルパー・コンポーネントはデータを大量に取得するといった使い分けをする。また、アプリケーションがOracleとSQL Serverのように複数のデータベースに対応するような場合は、同じインターフェイスを持つ2つのデータアクセス・ヘルパー・コンポーネントを作成することもあるだろう。ただし、データソースを変更する際は必ず追加のテストを実施するようにする。

■サービス・エージェント

 「サービス・エージェント」は、外部サービス固有のプロトコルを隠ぺいするコンポーネントだ。サービス・エージェントは、サービスのためのデータアクセス・ロジック・コンポーネント、またはサービスのプロキシだと考えると理解しやすいかもしれない。

役割

 サービス・エージェントは以下のことを実現するために使用する。

  • 1つのサービスに対するアクセスをカプセル化する

  • 外部サービスのデータ・フォーマットやスキーマの変更がビジネス・プロセスに影響を及ぼさないようにする

  • ビジネス・コンポーネントに対し、統一的な入出力フォーマットを提供する

 これらに加えて、必要なら以下の処理も行う。

  • 外部サービスとやりとりするデータを検証する

  • 頻繁に実行される問い合わせの応答データをキャッシュする

  • サービスへのアクセスを承認する

  • サービスに対し、正しいセキュリティ・コンテキストをセットしたり、正しい資格情報を提供したりする

  • 暗号化など、通信路のセキュリティを確認する

  • 契約どおりのサービス・レベルが守られているか調べるためのモニタリング情報を提供する

 アプリケーションが外部サービスと非同期でメッセージを交換する場合、サービス・エージェントによる呼び出しの結果をビジネス層のサービス・インターフェイスで受け取ることになる。そのような送信と受信を正しく対応付けるには、以下の2つの方法がある。1つは、メッセージ中のビジネス・データで会話を同定する方法である。例えば注文IDなどが利用できる。もう1つは、独自のIDを生成するコンポーネントを使ってメッセージにIDを貼り付ける方法である。この場合、IDと会話状態を保存するデータベースが必要になる上、外部サービスでメッセージが解釈されるときにID情報が欠けてしまう危険性もある。

次回の内容

 今回の記事では、AAfNの第2章で示されている、各コンポーネントについての推奨される設計および実装を紹介した。次回の記事では、第3章で示されている、組織的ポリシーが設計に及ぼす影響について紹介する。End of Article


 INDEX
  [連載] アプリケーション・アーキテクチャ設計入門
  第3回 論理アーキテクチャを構成するコンポーネントの設計(ビジネス/データ層編)
    1.ビジネス層コンポーネントの設計(1)
    2.ビジネス層コンポーネントの設計(2)
  3.データ層コンポーネントの設計
 
インデックス・ページヘ  「アプリケーション・アーキテクチャ設計入門」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間