2

私は次の問題を抱えています：

サーバーサイド（マングース）にコレクションがありaccount、RESTAPIにexpress-resourceを使用しています。

accountこれで、コレクションのすべてのサブセットであるメンバーリスト（ObjectIdの配列）を含む他のいくつかのオブジェクト（プロジェクト、組織、タスク）があります。

MarionetteJSアプリケーションがクライアントサイドコレクションを処理しています。

APIの呼び出しを回避する方法を探しています。目標は、APIの呼び出しによってコレクションを取得することです。

私が持っているいくつかのアイデア：

  • 次のような各オブジェクトにリソースを追加する

    /api/organization/:organizationId/members/
/api/organization/:organizationId/project/:projectId/members/

  • 次のような基本リソースへのパラメータの追加

    /api/accounts/?ids=id

  • （組織から）可能な限り最大のアカウントのセットを取得し、このコレクション（クライアント側）から他のサブセットを取得します。

  • サーバー側のメンバーリストにメンバーを追加する

  • 単一アカウントの読み込み。メンバーのリストを繰り返し処理し、各メンバーをフェッチします。

ある種のベストプラクティスはありますか？私は最初のオプションがおそらく最高であることを知っていますが、おそらく私が逃したオプションがあります。

4

1 に答える 1

0

それはすべて、Mongoose データベースをどのように構築したかによって異なります。メンバー リストが組織、プロジェクト、またはタスク ドキュメントに含まれている場合、関心のある特定のフィールドを探す必要なく、ドキュメントのクエリによって必要なリストが得られます。

リストを別のドキュメントとしてコーディングした場合 (SQL の慣行のように聞こえます)、メンバーのリストを取得するために Node に新しいリソースを設定する必要があります。この場合、最初のオプションは URL 構造の観点からは適切に思えますが、実装 (サーバー側またはクライアント側での読み込み) はプロジェクトの特性によって異なります。Node を使用すると、小さなサーバーと重いクライアントが必要になると思います (通常のシナリオ)。そのため、最終的にはクライアントで実行することになります。

良い習慣として、MongoDB はドキュメント指向のデータベースです。それを最大限に活用するには、エンティティと関係について考えるのをやめて、それらが提供するドキュメントについて考えてください。多くの部分でデータが複製されることは非常に一般的です。各コレクションはドキュメントの一種であるため、クライアントがデータを表示するたびに、必要なすべての情報を含むドキュメントを取得します。

オンラインで MongoDB パターンを探してください。多くの優れた情報源があります。本の方がよければ、Chodorow の Definitive Guide または Copeland の Applied Design Patterns を探してください。

于 2014-02-26T14:21:41.043 に答える