好吧,因为在您的示例中,两个组合框都需要值,所以我会在第一页加载时加载。不需要单独的请求,除非这些组合框依赖于表单中的数据,然后在这种情况下,您别无选择,只能等待用户输入来确定。
那么,假设您有两个组合框,而第二个组合框由第一个组合选项级联?好吧,第一个组合框不会改变 - 所以在页面加载时加载它,无论如何你都必须这样做。编写单独的事件或代码来加载必须首先加载的第一个组合是没有用的。
但是,第二个组合框呢?好吧,既然它的值是基于第一个的,那么再一次,你别无选择,是吗?
所以,我没有看到任何真正的用例,如果两个组合框彼此独立,那么我认为几乎没有理由需要单独的请求,并且首先加载两个组合框页面加载在这里还不够? (那么您不需要任何单独的请求)。
现在,如果有某种选项卡或 UI 并且用户不能立即看到或使用组合框,或者甚至可能永远不会从选项卡控件中选择某个选项卡?好吧,在这种情况下,您可以通过不填写组合框来加快页面加载速度,直到用户到达表单的该部分(可能是一些弹出对话框,或者可能是某种向导步骤)。
但是,再一次,如果两个组合框不相互依赖?然后我认为没有理由使用两个请求或事件来加载它们。但话又说回来,问题是你过去是如何加载组合框的?
我的意思是,如果每个组合框都是一些 ajax 调用,那么继续使用其中的两个,并保留这两个请求。由于尝试合并,或者将两个 ajax 调用填充两个组合框作为一个调用是一种痛苦,并且不遵循重用设计模式。结果是混乱的代码,更糟的是迫使你编写做两件事的代码。
我的意思是,如果您构建了一个很好的通用例程来调用 + 填写组合框,然后继续使用该代码来填写第二个。我不会破坏非常好的工作代码来以某种方式填写页面上的两个简单组合框并尝试使用一个请求从组合框中进行该归档。
正如我所说,如果组合框在页面加载开始时就在清晰的视图中,那么在第一页加载后的代码就是这样做的地方,除非出现一些相当大的性能问题。因此,您现在没有任何单独的请求来填写组合,是吗?
但话又说回来,一个组合框适用于 30 个,也许是 50 个选项的顶部,然后,您需要一个不同的 UI,因此再一次,这样做在性能方面也没有问题怎么样,是吗?
如果您试图修复或避免性能问题?然后你在combo box里放了太多的选项,那是错误的ui选项,然后再一次,你没有这个问题,是吗?