将数据保留在会话中与在回发时填充
将数据集保留在会话中或在每次回发时填充数据集哪个更好？
What is preferable, keeping a dataset in session or filling the dataset on each postback?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
将数据集保留在会话中或在每次回发时填充数据集哪个更好？
What is preferable, keeping a dataset in session or filling the dataset on each postback?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（11）
这取决于很多因素。 如果您的会话是 inproc 或在状态服务器上，通常最好不要在会话内存中保留太多项目，因为它的可扩展性较差。
如果您的会话驻留在数据库上，最好重新查询并重新填充数据集，除非执行查询的成本很高。
That would depend on many factors. It is usually best not to keep too many items in session memory if your session is inproc or on a state server because it is less scalable.
If your session resides on the database, it might be better to just requery and repopulate the dataset unless the query is costly to execute.
不要使用会话！ 如果用户打开带有不同请求的第二个选项卡，会话将被重用，并且结果将不是他/她期望的结果。 您可以结合使用 ViewState 和 Session，但在使用缓存之前仍然要测量在没有任何缓存的情况下可以处理多少数据。
Don't use the session!!! If the user opens a second tab with a different request the session will be reused and the results will not be the ones that he/she expects. You can use a combination of ViewState and Session but still measure how much you can handle without any sort of caching before you resort to caching.
这取决于您执行此操作的强度以及会话数据在服务器上的存储位置。
将数据集保留在会话中肯定会影响内存使用。 所有会话变量都存储在内存中，如果使用 SQL Server 状态，则存储在 SQL Server 中。 您还可以使用状态服务器模式将负载卸载到不同的计算机。
序列化/反序列化方面。 如果您使用非常大的数据集，可能会严重影响服务器端性能。
另一方面，页面上的视图状态非常大可能会成为真正的性能杀手。 因此，我会将数据集保留在会话或缓存中，并寻找“outproc”方式来存储该会话数据。
It depends how heavily you will do that and where your session data is stored on the server.
Keeping the datasets in session surely affects memory usage. All of the session variables are stored in memory, or in SQL server if you use SQL Server state. You can also offload the load to a different machine using the State Server mode.
The serialization/deserialization aspect. If you use insanely large datasets it could influence server seide performance badly.
On the other hand having very large viewstates on pages can be a real performance killer. So I would keep datasets in session or in the cache and look for an "outproc" way to store that session data.
由于我希望尽可能少地进行数据库操作，因此我会将数据保留在会话中，但我不确定最好的方法是什么。 我如何处理并发性，而且由于当两个用户同时使用页面时数据是共享的，我如何确保他们每个人在会话中都有自己的数据集？
Since I want as few database operations as possible, I will keep the data in session, but I'm not sure what would be the best way to do it. How do I handle concurrency and also since the data is shared when two users simultaneously use the page how can I make sure each of them have their own set of data in the session?
如果它不是太大和/或数据库又远又慢，我通常将其保留在会话中。 如果数据量很大，一般情况下最好重新加载。
有时我使用Cache，我第一次从Db加载并将其放入缓存中。 在回发期间，我检查缓存，如果它是空的，我会重新加载。
所以服务器自己管理缓存。
I usually keep it in session if it is not too big and/or the db is far and slow. If the data is big, in general, it's better to reload.
Sometimes I use the Cache, I load from Db the first time and put it in the cache. During postback I check the chache and if it is empty I reload.
So the server manage the cache by itself.
会话的问题在于，如果它在 proc 中，它可能会消失，这不太好，如果它是状态服务器，那么你必须序列化，如果它是 sql sate，你无论如何都要进行往返！
如果结果集很大，请进行自定义分页，以便您只返回总结果的一小部分。
然后，如果您认为多个用户会看到此结果集，则将每个页面作为用户页面放入缓存中，以确保在数据更改或一段时间未访问数据后更新缓存。
如果你不想进行多次往返并且你认为你有足够的内存，那么可以将整个数据集放入缓存中，但要小心它不会破坏网络服务器。
使用缓存意味着用户不需要自己的数据集，而是使用全局数据集。
就并发而言，当您加载插入/编辑页面时，您需要用新数据填充它并在添加/更新后更新缓存。
the trouble with the session is that if it's in proc it could disappear which isn't great, if it's state server then you have to serialize and if it's sql sate your're doing a round trip anyway!
if the result set is large do custom paging so that you are only returning a small subset of the total results.
then if you think more than one user will see this result set put each page in the cache as the user pages making sure that the cache is renewed when the data changes or after a while of it not being accessed.
if you don't want to make many round trips and you think you've got the memory then bung the whole dataset in the cache but be careful it doesn't melt the web server.
using the cache means users don't need their own set of data rather they use the global set.
as far as concurrency goes when you load up the insert/ edit page you need to populate it with fresh data and renew the cache after the add/update.
我是解耦的坚定信徒，而且我很少（如果有的话）认为有必要将完整的数据集扔到用户界面上。
您实际上应该只将对象传递给需要使用的 UI，因此除非您要显示一个大图表或某种需要显示数据之间关系的数据结构，否则不值得为此付出代价。
如果适用，较小的数据子集效率要高得多。 您的应用程序实际上是否在 UI 上使用了数据集中的所有功能？ 如果没有，那么最好的方法是仅传递您正在显示的数据。
如果您将数据绑定到控件并通过它进行排序/分页等，您可以用更小的代码片段实现许多接口，使数据集能够支持此操作。
在这一点上，我会在缓存中保留大部分静态的数据（例如，它不经常更新）。 因此，您需要查看数据更新的频率，然后才能真正做出决定。
最后，我要再说一遍，我认为在 UI 中使用数据集的需要非常非常少……这是一个非常重的数据对象，考虑数据需求的成本效益与实现的简便性相比，可能远远超出超过了缓存数据集的需要。
恕我直言，如果您担心性能或内存利用率，则数据集很难使用。
I'm a big believer in decoupling and i rarely, if ever, see the need to throw a full dataset out to the user interface.
You should really only pass objects to the UI which needs to be used so unless you're showing a big diagram or some sort of data structure which needs to display relationships between data it's not worth the cost.
Smaller subsets of data, when applicable, is far more efficient. Is your application actually using all features within a dataset on the UI? if not, then the best way to proceed would be to only pass the data out that you're displaying.
If you're binding data to a control and sorting/paging etc through it, you can implement a lot of the interfaces which enables the dataset to support this, in a lot smaller piece of code.
On that note, i'd keep data, which is largely static (e.g. it doesn't update that often) in the cache. So you need to look at how often the data is updated before you can really make a decision for this.
Lastly, i'll say this again, i see the need to utilise a dataset in the UI very, very rarely..it's a very heavy data object and the cost benefits of looking at your data requirements, versus ease of implementation, could far outweigh the need to cache a dataset.
IMHO, datasets are rather bad to use if you're worried about performance or memory utilisation.
您的回答并未暗示数据的用途。 是参考数据吗？ 用户是否主动更新？ 是否有多个用户在任一时间都具有更新访问权限？
如果没有比您提供的更好的信息，请遵循公认的智慧，即在会话中保留大量数据是保证您的应用程序不会扩展并且需要大量资源来服务少数用户的一种方法。人们。
通常有更好的方法来管理大型数据集，而无需将所有数据加载到内存中。
如果做不到这一点，如果您的应用程序数据需求确实巨大，那么请考虑具有 Web 服务后端的重型客户端。 它可能比制作网页更适合。
Your answer doesn't hint at the use of the data. Is it reference data? Is the user actively updating it? Is more than one user meant to have update access at any one time?
Without any better information than you provided, go with the accepted wisdom that says keeping large amounts of data in session is a way to guarantee that your application will not scale and will require hefty resources to serve a handful of people.
There's are usually better ways to manage large datasets without resorting to loading all the data in-memory.
Failing that, if your application data needs are truly monsterous, then consider a heavy client with a web service back-end. It may be better suited than making a web page.
正如其他答案所指出的，答案“取决于”。 不过，我假设您正在谈论用户之间共享的数据。 在这种情况下，您不应该将数据集存储在用户会话中，而是在回发时重新填充。
此外，您应该在应用程序的数据访问层附近填充缓存，以提高交互性能并减少数据库负载。 缓存的设计将再次取决于数据的类型（只读与读/写与大多数读）。
这种方法将用户会话（UI 层概念）与数据管理分离，并提供了支持共享使用缓存数据的额外好处（在数据在用户之间通用的情况下）。
As other answers have noted, the answer "depends". However I will assume that you are talking about data that is shared between users. In that case you should not store the dataset in the user's session, but repopulate on postback.
In addition, you should populate a cache near the data access layer of your application to increase interactive performance and reduce load on the database. The design of your cache will again depend on the type of data (read-only vs. read/write vs. read-mostly).
This approach decouples the user session (a UI-layer concept) from data management, and provides the added benefit of supporting shared use of cached data (in cases where data is common across users).
都不要——不要“保留”任何东西！ 仅显示用户需要查看的内容并构建有效的分页方案以向后或向前查看行。
RP
Neither--don't "keep" anything! Display only what a user needs to see and build an efficient paging scheme to see rows backwards or fowards.
rp
继续会议。 如果需要，可以选择重新填充，例如会话内存被擦除。
Keep in session. Have option to repopulate if you need to, for example if the session memory is wiped.