在ASP.NET网站中使用静态成员是不好的做法？

Question

据我所知，ASP.NET网站的所有用户都会共享一个静态成员;但在这种特殊情况下 - 这正是我想要的。

这是一个私人使用的网页，我把它放在一起，以促进两个用户之间的基于网络的聊天。我想避免将数据持久化到数据库或数据文件，并且我认为我可以将最后的X消息存储在静态并发队列中。这似乎在我的开发机器上运行良好。

我对ASP.NET很缺乏经验，但在我发现的所有例子中，都没有使用这种方法。这是一个不好的做法，我应该注意到“陷阱”吗？我可以看到的替代方案是使用数据库。但我觉得这将是更多的努力，我的猜测，是更多的资源（我认为我的'缓冲区'的消息将需要大约40kb的内存，并节省了相当多的数据库之旅）。

Answer 1

假设你确保整个事情都是线程安全的，那就行了。

但是，IIS可以随时回收您的AppDomain，因此当您不期望它时，您的队列可能会被吹走。

Answer 2

即使IIS不会偶尔刷新并重新启动AppDomain，为此目的使用静态变量听起来像是一个臭臭的黑客。

HttpApplicationState类提供对可用于存储信息的应用程序范围缓存的访问。

ASP.NET Application State Overview

Answer 3

只要您的要求不变，您可以随意丢失服务器端的所有消息，这是完全正常的。

我会稍微重构一下代码，以提供“消息存储”界面，以简化代码的测试（如果你决定让它变得更复杂/持久/多用户，将来会有潜在好处。）

静态存储方法（或HttpApplicationState）的专业版：

• 服务器端存储消息没有问题 - 减少隐私问题。没有什么是永久存储的，所以你可以说出你想要的任何东西。
• 非常简单的实施。
• 非常适合IM /电话交谈。
• 单个服务器案例中不太可能出现性能问题

缺点：

• 消息可能会丢失。可以通过在客户端上存储历史记录来缓解（即在同一网页上使用AJAX查询检索消息）
• 如果涉及更多用户时数据是敏感的/或者与其他代码共享应用程序则需要更加小心，因为每个人都可以看到静态数据。与任何其他存储空间也没什么不同。
• 无法直接迁移到多个服务器/ Web园景。 2人聊天服务器的问题真的不太可能。

Answer 4

当然，我在过去看到的一个问题是使用Web Gardens的静态变量。

看到这个问题： Web Garden and Static Objects difficult to understand

请注意讨论的重点：

  

静态对象不会在网络花园/网络农场中共享。