保持会话中的数据与回发时填充

题

什么是优选的，将数据集保存在会话中或在每个回发中填充数据集？

解决方案

这取决于很多因素。如果会话是inproc或状态服务器，通常最好不要在会话内存中保留太多项目，因为它的可伸缩性较低。

如果您的会话驻留在数据库上，那么重新查询和重新填充数据集可能会更好，除非查询的执行成本很高。

其他提示

不要使用会话!!!如果用户打开具有不同请求的第二个选项卡，则会话将被重用，结果将不是他/她期望的结果。您可以使用ViewState和Session的组合，但在使用缓存之前，仍可以测量无需任何缓存即可处理的内容。

这取决于您将做多少以及会话数据存储在服务器上的位置。

保持会话中的数据集肯定会影响内存使用。如果使用SQL Server状态，则所有会话变量都存储在内存中或SQL Server中。您还可以使用State Server模式将负载卸载到其他计算机。

序列化/反序列化方面。如果您使用疯狂的大型数据集，则可能会严重影响服务器的性能。

另一方面，页面上非常大的视图状态可能是真正的性能杀手。所以我会将数据集保存在会话中或缓存中，并查找“outproc”。存储会话数据的方法。

由于我希望尽可能少的数据库操作，我会将数据保存在会话中，但我不确定最好的方法是什么。如何处理并发性，并且由于当两个用户同时使用页面时共享数据如何确保每个用户在会话中拥有自己的数据集？

如果它不是太大而且/或者db很远很慢，我通常会将它保持在会话中。如果数据很大，通常最好重新加载。

有时我使用Cache，我第一次从Db加载并将其放入缓存中。在回发期间，我检查了chache，如果它是空的，我会重新加载。所以服务器自己管理缓存。

会话的问题在于，如果它在proc中它可能会消失，这不是很好，如果它是状态服务器那么你必须序列化，如果它是sql sate你无论如何都要进行往返！

如果结果集很大，请执行自定义分页，这样您只返回总结果的一小部分。

然后，如果您认为多个用户将看到此结果集将每个页面作为用户页面放入缓存中，以确保在数据更改时或在一段时间未访问之后更新缓存。

如果你不想进行多次往返并且你认为你已经有了内存然后将整个数据集打包到缓存中，但要小心它不会融化Web服务器。

使用缓存意味着用户不需要他们自己的数据集，而是使用全局集。

就加载插入/编辑页面时的并发性而言，您需要使用新数据填充它并在添加/更新后续订缓存。

我非常相信解耦，我很少（如果有的话）看到需要将完整的数据集输出到用户界面。

您应该只将对象传递给需要使用的UI，除非您显示一个大图或某种需要显示数据之间关系的数据结构，否则不值得花费。

较小的数据子集（如果适用）效率更高。您的应用程序是否实际使用UI上数据集中的所有功能？如果没有，那么最好的方法就是只传递你正在显示的数据。

如果您通过它将数据绑定到控件和排序/分页等，您可以实现许多接口，使数据集能够以更小的代码段支持这一点。

就此而言，我会保留数据，这些数据在缓存中基本上是静态的（例如，它不经常更新）。因此，您需要先了解数据的更新频率，然后才能真正做出决定。

最后，我再说一遍，我认为需要在UI中非常非常少地使用数据集..这是一个非常繁重的数据对象，以及查看数据需求的成本优势，而不是实现的简易性，可能远远超过缓存数据集的需要。

恕我直言，如果您担心性能或内存利用率，数据集使用起来会很糟糕。

您的回答并未暗示使用数据。它是参考数据吗？用户是否主动更新它？是否有多个用户在任何时候都有更新权限？

如果没有比您提供的更好的信息，请遵循公认的智慧，即在会话中保留大量数据是保证您的应用程序不规模并且需要大量资源来服务的一种方式少数人。

通常有更好的方法来管理大型数据集，而无需在内存中加载所有数据。

如果你的应用程序数据需求真的很糟糕，那就考虑一下，那么考虑一个带有Web服务后端的繁重客户端。它可能比制作网页更合适。

正如其他答案所指出的那样，答案“取决于”。但是，我将假设您正在讨论用户之间共享的数据。在这种情况下，你应该不将数据集存储在用户的会话中，而是在回发时重新填充。

此外，您应该在应用程序的数据访问层附近填充缓存，以提高交互性能并减少数据库的负载。缓存的设计将再次取决于数据类型（只读与读/写与主要读取）。

此方法将用户会话（UI层概念）与数据管理分离，并提供支持缓存数据共享使用的额外好处（在数据在用户之间通用的情况下）。

两者都没有 - 不要“保持”什么！仅显示用户需要查看的内容并构建有效的分页方案以查看向后或向前的行。

继续开课。如果需要，可以选择重新填充，例如擦除会话内存。

许可以下： CC-BY-SA 和归因