我有一个方案可以优化我的网络应用在会话中存储数据并检索它的方式。我应该指出我正在使用SQL Server作为我的会话存储。
我的方案是我需要存储一个映射到用户会话中字符串值的唯一ID列表供以后使用。我继承的当前代码是使用带有自定义对象的List<T>但我已经可以看到某种字典对于性能来说要好得多。
我已经测试了两个替代方案的想法：
在会话中存储Dictionary<int, string>。当我需要返回字符串时，我从会话中获取字典一次，并可以测试字典对象上的每个ID。
由于会话基本上类似于字典本身，因此使用唯一的会话密钥将字符串直接存储在会话中，例如Session["MyString_<id>"] = stringValue"。从会话中获取价值基本上是反向操作。
我的测试结果显示以下基于我需要做的操作并使用100个字符串：
从这些结果中我看到我在会话中节省了一些空间（可能是因为我没有得到序列化字典对象的开销）并且从会话中获取值时似乎更快，可能是因为字符串比对象更快地反序列化。
所以我的问题是，在会话中存储大量较小的对象而不是一个大的对象是否更好？存储大量较小的物体与一个我没见过的较大物体有什么不利之处吗？
答案 0 :(得分：1)
序列化和搜索大型对象会受到惩罚（由于需要表示更复杂的结构，它们占用更多空间和处理器时间）。
当你只能做一次时，为什么要进行2次搜索。
此外，所有处理缓存/存储解决方案的文档都提到，基于计算密钥从列表中序列化单个值要高效得多，而不是存储所有字典并检索它并在其中搜索。 / p>
答案 1 :(得分：0)
我认为你几乎已经回答了自己的问题，表明是的，反序列化对象存在开销，但我认为真正的原因应该是可管理性和可维护性。
当你谈论100个对象时，存储差异的大小将是最小的，但是当你将其扩展到1000个对象时，差异也会增加，特别是如果你使用复杂的自定义对象。如果您的应用程序中有许多用户都使用1000个会话，那么您可以想象这是如何不可扩展的。
此外，通过拥有许多会话对象，您无疑将需要编写更多代码来处理每个不同的对象。这可能不是更多，但肯定更多。这也可能使开发人员更难以理解您的推理等因此扩展您的代码。
如果你能用IEnumerable或IDictionary等单一的准系统格式处理会话，那么即使涉及到一点点开销，我认为这也是可取的。