存储库模式中的分页、排序等在哪里?

发布于 2024-10-18 01:39:05 字数 296 浏览 2 评论 0原文

在 ASP.NET 存储库模式项目中,我们将数据分页和排序的逻辑放在哪里?

应该放在服务层还是放在控制器中,让控制器直接调用存储库?控制器-> 此处显示了 jquery 网格的存储库。

但与那篇文章不同的是,我的存储库返回 IQueryable

Where do we put the logic for paging and sorting data in an asp.net repository pattern project?

Should it go in the service layer or put it in the controller and have the controller directly call the repository? Controller -> Repository is shown here for a jquery grid.

But unlike that article, my repository returns IQueryable<datatype>

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

当梦初醒 2024-10-25 01:39:05

如果您的存储库返回物化序列(ICollectionList)等,则它应该进入存储库。

但是如果您返回 IQueryable; (就像我一样),我希望您在控制器和存储库之间有一个服务层,它在 IQueryable 上执行查询并将它们具体化为具体的集合。

所以,我会把分页放在服务层。

像这样的东西:

public PagedList<T> Find(Expression<Func<T,bool>> predicate, int pageNumber, pageSize)
{
   return repository
             .Find()
             .Where(predicate)
             .ToPagedList(pageNumber, pageSize);
}

.ToPagedList 可以是一种扩展方法,它应用您需要的分页并将项目投影到 PagedList

有许多 PagedList 实现。我喜欢Rob Conery 的。具有您的视图所需的属性,因此您可以绑定到 PagedList 并创建一个 HTML Helper 来非常轻松地呈现页码。任何分页列表 LINQ 实现的唯一问题是 Count() 操作(记录数)需要在服务器上完成,因此会导致 2 次往返。

您不希望将非具体化查询返回到您的视图,因为 IMO 这打破了 MVC 模式。

每次转到新页面时,调用您的服务来检索所需的结果。

It should go in the Repository if your Repository returns materialized sequences (ICollection<T>, List<T>), etc.

But if your returning IQueryable<T> (like i am), i hope you have a service layer mediating between your Controllers and Repository, which executes queries on the IQueryable and materialises them into concrete collections.

So, i would put the paging in the service layer.

Something like this:

public PagedList<T> Find(Expression<Func<T,bool>> predicate, int pageNumber, pageSize)
{
   return repository
             .Find()
             .Where(predicate)
             .ToPagedList(pageNumber, pageSize);
}

.ToPagedList can be an extension method that applies the paging you require and projects to a PagedList<T>.

There are many PagedList<T> implementations out there. I like Rob Conery's one. Has properties that your View requires, so you can bind to a PagedList<T> and create a HTML Helper to render out the page numbers very easily. The only problem with any paged list LINQ implementation is the Count() operation (for the number of records) needs to be done on the server and hence results in 2 round trips.

You don't want to be returning non-materialized queries to your View's, as IMO this breaks the MVC pattern.

Each time you go to a new page, call your service to retrieve the required result.

烟凡古楼 2024-10-25 01:39:05
  • 排序:对于大型结果集应该在存储库中完成; 可以在小型集合的控制器内部完成(即没有分页)。
  • 分页:IMO 存储库应该公开返回集合切片的方法(与分页并不完全相同)。这意味着,应该有一种方法要求存储库返回查询,从索引 z 开始,针对接下来的 y 项。然后,与特定页面大小(或页面索引)相关的所有内容都应保留在控制器内。这样您就可以优化数据检索,但无需将模型与特定的表示要求耦合。
  • Sorting: should be done in the repository for large result sets; may be done inside the controller for small collections (i.e. without paging).
  • Paging: IMO the repository should expose a way of returning collection slices (which is not exactly the same as paging). Meaning, there should be a way of asking the repository to return a query, starting at the index z and for the next y items. Then everything related to the particular page size (or page index) should be kept inside the controller. That way you can optimize data retrieval, but without coupling your model to a particular presentation requirement.
冷了相思 2024-10-25 01:39:05

排序和分页是数据功能。它应该进入存储库。

Sorting and paging are data functions. It should go in the repository.

无尽的现实 2024-10-25 01:39:05

存储库应该返回一个“PageableResultSet”或类似的东西,它负责分页。

The repository should return a 'PageableResultSet', or something like that, which is responsible for the paging.

安稳善良 2024-10-25 01:39:05

我认为分页应该放在存储库中。请参阅我在另一个问题上发布的答案。

存储库和持久性再次无知

I believe paging should go in the repository. See this answer I posted on another question.

Repositories and persistence ignorance again

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文