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

前端之家收集整理的这篇文章主要介绍了asp.net-mvc – 存储库模式 – 如何正确处理JOIN和复杂查询?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有Repository模式的问题 – 如何在几个存储库之间执行JOIN操作.在这个项目中,我们使用MVC,EF,DDD.我知道这个问题在这里有好几次,我稍后会提到这些问题.

在通用存储库模型(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(我赞成这个选项)
>完全不一样的东西

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

解决方法

意味着将持久性泄漏到应用程序中 – 反模式,意大利面条代码.
>如何与(1)不同?仍然是同一个问题.
>有点靠近…
>使用查询对象模式.将复杂查询封装在与存储库一起存在的基于任务的对象中.它可以返回为视图而不是域对象优化的DTO.
>严格依靠QO将引导您进入称为CQRS – 命令查询责任分离的体系结构.

还有一件事.实体没有1:1的匹配:repo.只有聚合应该有一个存储库,而不是每一个实体.

原文链接:https://www.f2er.com/aspnet/246502.html

猜你在找的asp.Net相关文章