调用基于ADO.NET存储过程的ASP.NET Core Web API的MVC项目如何实现分页、排序、筛选？

底层逻辑下沉到存储过程层 #

你目前已经通过ADO.NET调用SQL Server存储过程，直接将三类逻辑放到存储过程内实现，是性能最优的选择：

• 新增可空的筛选参数，对应你需要的筛选维度，存储过程内通过参数化的动态条件过滤数据，注意用QUOTENAME处理字段类参数、避免SQL注入风险
• 新增排序字段、排序方向两个参数，在存储过程内实现动态排序逻辑
• 新增pageIndex（当前页码）、pageSize（每页条数）两个分页参数，用SQL Server原生的OFFSET ... FETCH NEXT ... ROWS ONLY语法实现分页，同时额外返回符合条件的总数据条数，用于上层计算总页数

Web API层封装统一入参出参结构 #

统一查询入参类 #

定义通用的查询参数接收模型，所有需要分页排序筛选的接口都复用这个结构：

public class QueryRequest
{
    public int PageIndex { get; set; } = 1;
    public int PageSize { get; set; } = 10;
    public string? SortField { get; set; }
    public string? SortDirection { get; set; } = "ASC";
    // 按需扩展筛选字段，例：
    public string? Keyword { get; set; }
    public DateTime? CreateTimeStart { get; set; }
}

统一分页出参类 #

封装通用的分页结果结构，返回给调用方：

public class PagedResponse<T>
{
    public List<T> Data { get; set; } = new();
    public int TotalCount { get; set; }
    public int PageIndex { get; set; }
    public int PageSize { get; set; }
    public int TotalPage => (int)Math.Ceiling(TotalCount / (double)PageSize);
}

API接口接收QueryRequest参数后，透传给ADO.NET层调用存储过程，拿到分页数据和总条数后封装为PagedResponse<T>返回即可。

MVC层适配逻辑 #

因为两个项目在同一个解决方案内，建议把上述公共模型类抽为单独的共享类库项目，两端都引用，避免重复写代码：

• MVC的Controller接收前端提交的页码、排序规则、筛选条件，映射为QueryRequest参数后调用Web API接口
• 拿到API返回的PagedResponse<T>后直接传给视图，视图根据返回的总页数、当前页数据渲染分页控件、列表内容、筛选和排序状态即可
• 如果需要无刷新交互，用Ajax提交参数给MVC的Action，返回分部视图或者JSON渲染页面即可

方案优势 #

• 性能开销最低：所有过滤、排序、分页逻辑都在数据库层完成，API仅返回当前页需要的少量数据，不会出现全量数据传输导致的带宽占用高、MVC端内存溢出问题
• 维护成本低：公共逻辑和模型只需要写一次，修改时仅需调整对应层的代码，不会出现两端逻辑不一致的问题
• 可靠性高：SQL Server原生的分页排序筛选经过大量生产环境验证，比在MVC内存中处理全量数据的稳定性高得多

内容的提问来源于stack exchange，提问作者user9555045