javascript - 分页时 MVC 持久模型

Question

我有一个带有复选框的下拉列表。所选值绑定(bind)到我的 View 模型。使用 PagedList.Mvc 对数据进行分页。当我选择一些复选框然后点击搜索按钮时，一切正常，但是当我单击另一个页面时，复选框列表变为空，因此列表会丢失选中的内容。如何让模型在分页时保持不变。

所以我的 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;
    }
}

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

Answer 1

在这种情况下，我总是喜欢深入了解底层细节，因为我认为这有助于理解为什么事情是可能的或不可能的。然后，一旦您了解了这一点，您就可以找出如何解决限制。

也就是说，您在这里处理的是请求-响应和无状态的概念。让我们从无国籍开始。互联网(特别是 TCP/IP 协议(protocol))被设计为无状态的。互联网是一个网状网络，由许多不断加入和退出网络的连接设备组成。其起源于美国军方的研究机构 ARPA，其最初目的是提供一种能够在“枢纽”或集中式通信阻塞点遭受核攻击时幸存下来的通信系统。通过分散网络，可以切断多个中心，而通信仍然可以继续进行。但是，要实现这种网络设计，您不能有任何类型的状态，因为当客户端被迫连接到不同的服务器时，因为先前的服务器现在已离线，新服务器将不知道先前的通信客户有。因此，服务器响应请求所需的所有信息都必须在请求本身中。这给我们带来了请求-响应。

客户端向服务器发出请求，服务器发送响应。这是所有网络通信的根本基础。当您单击一个寻呼机链接时，您将向服务器发出下一页的 GET 请求，并且服务器会使用表示该页面的 HTML 文档进行响应。由于网络是无状态的，服务器用来构建响应的唯一信息是客户端在请求中发送的信息(例如，带有名称-值对“page=2”的查询字符串。如果您想要同样，您必须找到某种方法将其包含在查询字符串中，或​​者发送 POST 请求并将该数据包含在 POST 正文中。但是，虽然您可以单击链接发出 POST，它需要 JavaScript 更改链接的默认行为(发送 GET)，但它还需要 JavaScript 动态更改链接的 href 以在查询字符串中包含额外的数据。

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

继续上面的讨论， session 是有状态的，所以您可能想知道当网络是无状态时这怎么可能。答案是 session 是“假”状态。实际上，服务器正在保存信息并发出代表“ session ”的 token 。该 token 作为 cookie 发送到客户端。 Web 浏览器(最典型的客户端)被编程为在每次请求时将从服务器接收到的所有 cookie 发送回服务器。结果是，该请求在技术上仍然具有服务器所需的所有信息，因为 session token 足以允许服务器找到以前的 session 数据并“恢复”它。