asp.net-mvc – 存储库模式 – 如何正确处理JOIN和复杂查询？

在通用存储库模型(IRepository)和特定存储库模型之间,我选择了特定的选项,因为我认为ORM(在我们的例子中是EF)作为通用存储库模式本身,所以增加另一个通用存储库是没有意义的,而是将存储库定制到域的需求.

问题是我有几个(〜10)个表,每个都有很多行(百万),我需要执行JOIN,所以使用IList或IEnumerable是不可行的选择.

我的理解(和我的观点)是IQueryable不应该离开存储库(“DAL中会发生什么,应该保留在DAL”).暴露IQueryable并在LINQ中使用它可能会更简单,但是它强烈地违反了分离问题并破坏了存储库的作用 – 在这种情况下,服务将与存储库一样做.要选这几个,这些文章备份了这个观点(或者相信信念)：

To return IQueryable<T> or not return IQueryable<T>

Should I return IEnumerable<T> or IQueryable<T> from my DAL?

http://www.shawnmclean.com/blog/2011/06/iqueryable-vs-ienumerable-in-the-repository-pattern/

http://blog.ploeh.dk/2012/03/26/IQueryableTisTightCoupling/

还有类似的问题和解决方案,例如How to join Multiple tables using Repository Pattern & Entity Framework?提示.Include(),但是这不是许多表中重载表和连接的选项 – 每个JOIN,我们使用子选择来限制实际加入的内容.

这个问题(答案和评论) – How can I query cross tables with Repository Pattern? – 基本上提出了基于任务的差异化：为JOINS查询创建一个repository,并为每个实体操纵“常规”存储库.

我看到我们有这些选择：

>在服务中暴露IQueryable和执行JOIN复杂查询;我真诚地觉得这是反模式,我不喜欢这样.
>不要在这10个表中使用Repository并在服务中执行查询;一些文章建议使用EF是足够的(例如Is it okay to bypass the repository pattern for complex queries?),我不同意.
>使用基于任务的差异化,不要限制存储库1：1 repo：entity(我赞成这个选项)
>完全不一样的东西

那么 – 你会建议什么？一次又一次,谢谢.