MVC ストアフロントを見て、リポジトリ クラスから IQueryable が返されていることを確認しました。LINQ を使用していない場合、そのオブジェクトを返すことは理にかなっていますか? LINQ の場合は実行が遅延されるため、サービス レイヤーにフィルターを追加することは理にかなっていますが、LINQ を使用しない場合は多くの場合、DB でフィルター処理を行います。この場合、フィルタリングを行うメソッドをリポジトリに追加するだけでよいでしょうか? もしそうなら、サービスレイヤーは本当に役に立ちますか?
3 に答える
引数はどちらの方法でも作成できます。この最近のブログ投稿を参照してください。
Rob Conery が MVC Storefront に組み込んだ IQueryable は革新的ですが、リポジトリの作成に関しては決して標準ではありません。通常、リポジトリは、ドメインとデータベースのマッピングを担当します。IQueryable を返すことは実際にはマッピングを実行せず、それを行うためにサービス レイヤーに依存します。これには長所と短所がありますが、これが唯一の方法ではないということだけを言っておけば十分です。
ただし、コードがすべて重複しているため、サービスが少し臭くなることに気付くでしょう。たとえば、データベース内のすべてのユーザーのリストを取得するだけの場合は、リポジトリとサービス レイヤーの両方でその関数を定義する必要があります。ただし、サービス レイヤーが優れているのは、1 つの操作でデータベースとの間の複数のトランザクションが必要な場合です。
IQueryable をサービス層に公開する際に私が抱えている問題は、サービス層のコードを壊さずに Web サービスの背後にあるリポジトリ層をラップしたい場合、 ADO.NET Data Servicesを使用せずにはできませんが、すべてのリポジトリ コードは本質的に冗長になります。
小さなアプリではかなり生産的であると思いますが、スケーリングと配布を検討し始めると、良いことよりも悪いことが起こります.