リポジトリパターン-MVCストアフロント

Question

MVCストアフロントを見て、リポジトリクラスからIQueryableが返されることを確認しました。 LINQを使用していない場合、そのオブジェクトを返すことは理にかなっていますか？ LINQの場合、実行が遅延されるため理にかなっているため、サービスレイヤーにフィルターを追加することは理にかなっていますが、LINQを使用しない場合は、多くの場合、DBでフィルターを適用します。この場合、リポジトリにフィルタリングを行うメソッドを追加するだけですか？もしそうなら、サービス層は本当に便利ですか？

Answer 1

引数はどちらの方法でも作成できます。最近のブログ投稿をご覧ください：リポジトリでIQueryableを公開する必要がありますか？

Answer 2

Rob ConeryがMVC Storefrontに入れたIQueryableの内容は革新的ですが、リポジトリの作成に関しては決して標準ではありません。通常、リポジトリは、データベースとデータベースのマッピングを担当します。 IQueryableを返すことは実際にはマッピングを実行せず、それを行うためにサービス層に依存します。これには長所と短所がありますが、それが唯一の方法ではないというだけで十分です。

ただし、重複したコードが原因で、サービスが少し臭いになります。たとえば、データベース内のすべてのユーザーのリストを取得する場合は、リポジトリとサービスレイヤーの両方でその関数を定義する必要があります。ただし、サービスレイヤーが輝くのは、1回の操作でデータベースとの間で複数のトランザクションが必要な場合です。

Answer 3

IQueryableをサービスレイヤーに公開する際に発生する問題は、サービスレイヤーコードを壊すことなくリポジトリレイヤーをWebサービスの背後にラップしたい場合、 ADO.NET Data Services の場合、すべてのリポジトリコードは本質的に冗長になります。

小さなアプリにとってはかなり生産的だと思いますが、スケーリングと配布を検討し始めると、良いことより悪いことのほうが多くなります。