4

すべてのデータ アクセスのリポジトリ パターンから始まるマルチレイヤー アプリケーションがあり、サービス レイヤーに IQueryable を返します。すべてのビジネス ロジックを含むサービス レイヤーは、IList をコントローラーに返します (注: UI レイヤーには ASP.NET MVC を使用しています)。データ アクセス レイヤーで IQueryable を返す利点は、リポジトリを非常にシンプルにし、データベース クエリを延期できることです。ただし、サービス レイヤーでデータベース クエリをトリガーしているため、単体テストの信頼性が向上し、クエリを再形成する柔軟性をコントローラーに与えていません。しかし、私は' 最近、コントローラーが UI 固有のデータに対していくつかのプロジェクションを実行する必要があったため、クエリの実行をコントローラーに延期する方がパフォーマンスが大幅に向上するという状況に遭遇しました。さらに、oData などの出現により、エンドポイント (Web UI や Web API など) が IQueryable と直接連携する必要があるかどうか疑問に思い始めていました。あなたの考えは何ですか？サービス層から UI 層に IQueryable を返し始める時が来ましたか? それとも IList に固執しますか? あなたの考えは何ですか？サービス層から UI 層に IQueryable を返し始める時が来ましたか? それとも IList に固執しますか? あなたの考えは何ですか？サービス層から UI 層に IQueryable を返し始める時が来ましたか? それとも IList に固執しますか?

このスレッドはこちら: To return IQueryable<T> or not return IQueryable<T> は、IList を UI レイヤーに返すことを保証しているように見えますが、新しいテクノロジーやテクニックのために状況が変化しているのではないかと考えていました。

4

1 に答える 1

3

私は可能な限りIQueryableインターフェイスを使い続けるのが好きです。唯一の問題は、次のような場合に、複雑なフィルタリングを実行したり、コントローラーレベルでオンデマンドで再クエリを実行したりする場合です。

//DATA ACCESS
    public IQueryable<T> GetStudents()
    {
    return db.Students;
    }

そして、あなたのコントローラーでは、クライアントがその結果のいくつかのデータをフィルターにかけたいので、いくつかの再整形を行います。確かに、あなたはコントローラーレベルでそれをしたくなるでしょう：

var result = obj.GetStudents().Where(d=>d...);

私にとっては大丈夫ですが、他のモジュールが同じフィルターを使用する必要がある場合は、コントローラーレベルであるため、呼び出すことはできません。したがって、私にとっては、DRY、柔軟性、およびシステムの拡張性のバランスが取れています。完全にスケーラブルなシステムが必要な場合は、GetStudents（）メソッドにいくつかまたはいくつかのオーバーロードを実行し、コントローラーレベルでの再シャープ化を取り除く必要があります。

于 2010-03-30T19:26:53.353 に答える