データベース抽象化レイヤーで公開する機能は何ですか？
インターフェイスの背後にあるデータの永続性を抽象化する簡単な方法を設計しようとしていますが、どのように細かい粒度のコントロールを上位層に公開する必要があるかを理解するのに苦労しています。
制限、フィルター、次数など.
ダムデータリポジトリのインターフェースを定義することは、基本的なCRUD操作ではすべてうまく機能しますが、結果のフィルタリング、制限、マップ/リデュース、その他の変換または条件付き操作など、他のすべての一般的なデータベース機能はどうでしょうか。これらのタイプの操作は、永続化レイヤーが単なる取得/永続化ブラックボックスであるという意味で単一責任の原則に違反します。その結果、この機能は呼び出し側のコード側（つまり、サービスレイヤー）でより適切に実装されます。またはクライアント側））？
クライアント側の変換
パーシステンスレイヤーを大幅に簡略化しますが、個人的には、これらの操作をクライアント側で実行するのは非常に無駄だと思います。たとえば、ユーザーが10個のリソースのコレクションをクエリするか1000個のコレクションをクエリするかに関係なく、データベースは、とりわけ、帯域幅とキャッシュコストが発生するデータセット全体を返す必要があります。また、これらのクエリの多くはおそらくネイティブで大幅に最適化されており、これによってすべてがウィンドウの外に捨てられます。
スマートデータベースの抽象化
一方、このデータベース機能を永続化レイヤーで公開すると、インターフェイスの複雑さが大幅に増加し、おそらくデータベースドライバーの1：1ラッパーのように見えます（これは、私は推測する模擬テストの目的ですが、最初に抽象化を記述する目的を打ち負かしています）。
私の質問は、どの機能を公開し、何を非表示にしておくかについてのデータベース抽象化レイヤーを設計する際の一般的な経験則はありますか？
データベースシステムは、非常に異なるアプローチを実装できます。 SQLとNoSQLを比較するだけです。後者の場合は、比較 Key-Valueストアとグラフデータベース を比較します。したがって、これらのデータベースのすべての利点を備えた単一のAPIを提供する特効薬は見つかりません。したがって、範囲を絞り込む必要があります。
制限、フィルタリング、順序付けを考慮すると、それらの多くはデータベースのクエリに関連しています。だから私はあなたが間違いなくあなたのAPIでこれを処理する必要があると思います。そうしないと、苦しむ可能性があります。クライアントとAPIの間の余分な呼び出しのためではなく、クライアント側でそれを強制すると、アプリが必要以上にデータベースサーバーを要求するようになるためです。 クライアント側とサーバー側の処理 の従来の問題の1つの変形です。
ただし、独自の汎用APIを作成する場合を除いて、アプリケーションアーキテクチャから永続層を設計することを強くお勧めします。特に、アーキテクチャがメモリ内のオブジェクトとデータベース上のデータオブジェクト間のマッピングを処理する方法（例 オブジェクトリレーショナルマッピング ）。
この問題には、シリアライズ/デシリアライズの課題といくつかの類似点があります。つまり、オブジェクト間の関係、オブジェクトの構成、オブジェクトのコンテナーなどをマッピングする方法です...明確な図が得られたら、サポートに必要な操作でデータベースレイヤーを設計する必要がありますオブジェクトマッピングのプリミティブ。
データベースオブジェクトを制御するインメモリプロキシのマッピングについて、 プロキシデザインパターン を検討することから始めます。ここで提案するアプローチは、ユニバーサルデータベースラッパーの開発とは大きく異なります。ただし、基盤となるデータベースアーキテクチャを最大限に活用できる、つまりグラフデータベースとドキュメントデータベースを利用できるという利点があります。