分页时MVC持久模型

时间:2015-09-02 14:31:51

标签: javascript asp.net-mvc pagedlist

我有一个带有复选框的下拉列表。选定的值绑定到我的视图模型。使用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;
    }
}

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

1 个答案:

答案 0 :(得分:1)

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

即,在这里,您要处理请求 - 响应和无状态的概念。让我们从无国籍开始吧。互联网(特别是TCP / IP协议)被设计为无国籍。互联网是一个网状网络,由许多连接的设备组成,这些设备不断地从网络连接和丢弃。起源于美国军方的研究机构ARPA,其最初目的是提供一种能够在“集线器”或集中通信阻塞点的核攻击中幸存下来的通信系统。通过分散网络,可以切断多个集线器,并且通信仍然可以继续有增无减。但是,要实现这种网络设计,您不能拥有任何类型的状态,因为当客户端被迫连接到不同的服务器时,因为先前的服务器现在处于脱机状态,新服务器将不知道先前的通信客户了。因此,服务器响应请求所需的所有信息必须位于请求本身中。这使我们得到了请求 - 响应。

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

真正的最佳解决方案是将每个(检查项目和更改页面)视为单独的事物。检查项目后,您可以使用JavaScript将该信息动态发布到服务器,也可以提供提交按钮以允许用户手动发布。在服务器端,您可以将该值存储在会话中。然后,您可以简单地让分页工作,就像开箱即用一样,只需从会话中读取每个页面的选中值。

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