为什么在 Razor 视图中使用 @model IQueryable<>

Question

在 Razor 视图中使用

@model IQueryable<>

是个好主意吗？在 Razor 视图中使用

@model IQueryable<>

的任何合适场景？

我刚刚在一些旧代码中将

IQueryable<>

替换为

List<>

。公司里没有可以请教的老开发人员。

@model IQueryable<T>
@{
    ViewBag.Title = "Index";
}

<table class="table">
    <tr>
        <th></th>
        <th>Sn</th>
        <th>Kind</th>
    </tr>
    @{
        var count = 1;
    }
    @using (Entities db = new Entities())
    {
        foreach (var item in Model)
        {
            <tr>
                <td>
                    <button type="button" class="btn_delKind btn btn-danger" data-kind-id="@item.id">Delete</button>
                </td>
                <td>@count</td>
                <td>
                    @switch (item.Type)
                    {
                        case 0:
                            @Html.Raw("All")
                            break;
                        default:
                            @Html.Raw(db.LookupType.Find(item.Type).Name)
                            break;
                    }
                </td>
            </tr>
            count = count + 1;
        }
    }
</table>

编辑之前 - 我之前的观点：

1. 消耗更大的内存（资源问题）
2. 操作模型的方式将依赖于服务器端，很难转移到前端javascript（关注点分离）
3. 很可能会生成更多由 HTML 包围的 C# LINQ 代码。不是一个用于渲染的简单、静态、结构良好的对象。 （性能问题）

收集评论和答案后（谢谢）

1. 意外的内存使用
2. 意外的查询计数
3. 违反MVC模式

Answer 1

回答你的问题 - 不，没有理由在视图中使用

IQueryable<T>

。

IQueryable<T>

的全部目的是提供机制，允许您编写C#代码，可以将其转换为其他程序/工具可以理解的其他形式。在本例中，假设您使用实体框架，

IQueryable<T>

接口定义方法，允许实体框架将您的查询从 C# 转换为 SQL。这可以使用表达式树来完成。使用表达式树是

IEnumerable<T>

和

IQueryable<T>

之间的主要区别。

这不是真的，

IQueryable

比

IEnumerable

使用更多内存。使用

IEnumerable

可以将对象保留在内存中，因此必须为集合中的每个对象分配空间。

IQueryable

定义了查询数据的接口，因此您不需要在内存中存储任何内容。

在您看来，您需要能够迭代您的集合并显示特定的数据集。要做到这一点，

IEnumerable

提供的方法就足够了。在您看来，使用

IQueryable

不会对您有任何好处，但可能会导致很多问题，正如评论中已经提到的那样。