複数のデータベースを持つデータアクセス層の設計

Question

いくつかのデータベースを持っているという問題と、この場合にDALを効率的に設計する方法に関する多くの記事を読んでいます。多くの場合、フォーラムはリポジトリパターンを適用することを提案していますが、これはほとんどの場合うまくいきます。

しかし、私は別の状況で自分自身を見つける。 Oracle、OLE DB、SQLServerの3種類のデータベースがあります。現在、多くの異なるクラスを持つユニークなDALが存在し、対応するデータベースで実行されるために、下のレイヤにSQLクエリを送信します。システムの仕組みは、2つのデータベースがそれらの情報を読み取るためにのみ使用され、もう1つがこの同じ情報を格納するか、後で読み取るために使用されるということです。私は現在の実装に対してより良い設計を提案しなければならないが、3つのデータベースすべての共通インタフェースがアーキテクチャ上の観点から妥当性がないように思える。

この状況を解決するデザインパターンはありますか？ 3種類のDALを用意する必要がありますか？あるいは、おそらく、この問題にリポジトリパターンを適用することは可能です（そしてお勧めします）？

Answer 1

あなたの質問への回答は、おそらく非常に主観的なものになります。これらはいくつかの考えです。

コマンドとクエリの分離を適用できます。クエリ側は、ビジネス層またはドメイン層を迂回してデータレイヤーと直接統合され、返されるエンティティはデータベースからの読み取りとプロジェクト用に最適化されます。このレイヤーは、異なるデータベース呼び出しの結果をマージする責任もあります。

コマンド・サイドは、R/Wデータベースからマップされるドメインまたはビジネス・エンティティを使用するコマンド・ハンドラで構成されています。

このようにすると、公開するインターフェイスがより明確になり、ビジネス指向になります。

データアクセス層をカスタム作業単位とリポジトリで完全に抽象化することが本当に必要なのかどうかはわかりません。欠点を上回る利点はありますか？データベーステクノロジを変更する予定があるため、ほとんどありません。そしてもしあなたがそうしたら、とにかく書き換えを意味するでしょう。また、エンティティ・フレームワーク・コードを最初に使用する場合、すでに作業ユニットと抽象化がデータベースの上にあります。およびLINQを使用する柔軟性。

ボトムライン - オーバーエンジニアリングしすぎないようにしてください。物事をスーパージェネリックにすることができます。

Answer 2

コア/ビジネスコードは、アプリケーションのDALレイヤに配置されている契約/インターフェイス/クラスに決して依存しないでください。

データへのアクセスは、アプリケーションのビジネス/コア・レイヤーで実行できる必要があります。これは、SQLステートメントに依存することなく、また基礎となるデータ・アクセス技術を知らなくても可能です。

私はアプリケーションのコア部分から "SQL"ステートメントを削除する必要があると思います。 SQLはベンダーに依存し、特定のデータベースエンジンへの依存関係はすべてコアから取り除かれ、属しているDALに移動する必要があります。次に、DALの外にあるインターフェイスを作成し、次に、1つまたは複数のDALモジュール/クラスのインプリメンテーションクラスを作成する必要があります。あなたのDALはあなたのコアに依存することができますが、それ以外の方法ではありません。

この場合、リポジトリレイヤを使用できない理由はわかりません。私が読むことができるデータベースがあるとき、私は通常、リポジトリインターフェースの名前にICompanyRepositoryReadのようにこれを示すようにします。