分页时 MVC 持久模型

MVC Persist Model when paging

我有一个带有复选框的下拉列表。 selected 值绑定到我的视图模型。使用 PagedList.Mvc 对数据进行分页。当我 select 一些复选框然后点击搜索按钮时,一切正常,但是当我单击另一个页面时,复选框列表变为空,因此列表丢失了选中的内容。如何让模型在分页时持续存在。

所以我的 html 看起来像这样

    <ul class="dropdown-menu">
        @for (int i = 0; i < Model.Units.Count; i++)
        {
            @Html.CheckBoxFor(m => m.Units[i].Selected) 
            @Html.HiddenFor(m => m.Units[i].UnitId) 
            @Html.LabelFor(m => m.Units[i].Selected,
                       Model.Units[i].UnitName)
            <br />
            }
    </ul>

 <button class="btn btn-primary" type="submit" id="btnSave" name="Command" value="Save">Search</button>

并进一步向下分页

 @Html.PagedListPager(Model.SearchData, page => Url.Action("Index", new HistoricDataViewModel { Page = page }))

我的模型看起来像这样

public class HistoricDataViewModel
{
    public HistoricDataViewModel()
    {
        Page = 1;
    }

    public StaticPagedList<Data_Search_Result> SearchData { get; set; }
    public List<Units_Getall_Result> Units { get; set; }
    public int Page
    {
        get; set;
    }
}

当我点击搜索按钮时,它正在提交表单。问题是因为分页插件没有提交吗?

在这种情况下,我总是喜欢深入了解低级细节,因为我认为这有助于理解为什么事情是可能的或不可能的。然后,一旦你理解了这一点,你就可以弄清楚如何解决限制。

即,您在这里处理的是请求-响应和无状态的概念。让我们从无状态开始。 Internet(特别是 TCP/IP 协议)被设计为无状态的。互联网是一个网状网络,由许多连接的设备组成,这些设备不断地加入和退出网络。起源于 U.S 的研究机构 ARPA。军事,它的最初目的是提供一种通信系统,可以在 "hubs" 或集中式通信瓶颈的核攻击中幸存下来。通过分散网络,可以切断多个集线器,并且通信仍然可以继续进行。然而,要实现这种网络设计,你不能有任何状态,因为当客户端被迫连接到不同的服务器时,因为以前的服务器现在离线,新服务器不知道之前的通信客户有。因此,服务器响应请求所需的所有信息都必须在请求本身中。这将我们带到请求-响应。

客户端向服务器发出请求,服务器发送响应。这是所有网络通信的基础。当您单击其中一个寻呼机 link 时,您将向服务器发出获取下一页的 GET 请求,并且服务器会使用代表该页面的 HTML 文档进行响应。由于网络是无状态的,服务器必须使用的唯一信息来构建该响应是客户端在请求中发送的内容(例如,具有名称-值对 "page=2" 的查询字符串)。如果你想同样,保留选中的项目,您必须找到某种方法将其包含在查询字符串中或发送一个 POST 请求,该数据包含在 POST 正文中。但是,当您 可以使link点击发出POST,它需要JavaScript来改变link的默认行为(发送GET),但它会还需要 JavaScript 动态更改 link 的 href 以在查询字符串中包含额外数据。

实际上,最好的解决方案是将每个(检查项目和更改页面)视为单独的事情。检查项目后,您可以使用 JavaScript 将信息动态 post 到服务器,或者提供一个提交按钮以允许用户手动 post 它。服务器端,您可以将该值存储在会话中。然后,您可以简单地让分页像开箱即用一样工作,并简单地从每个页面的会话中读取选中的值。

继续上面的讨论,会话 状态,所以您可能想知道当网络是无状态的时候这怎么可能。答案是会话处于 "fake" 状态。幕后实际发生的事情是服务器正在保存信息并发出代表 "session" 的令牌。该令牌作为 cookie 发送到客户端。 Web 浏览器(最典型的客户端)被编程为在每次请求时将从服务器接收到的所有 cookie 发送回服务器。结果是请求在技术上仍然具有服务器需要的所有信息,因为会话令牌足以让服务器找到以前的会话数据并 "restore" 它。