1

我了解静态成员将由 ASP.NET 网站的所有用户共享；但在这种特殊情况下 - 这正是我想要的。

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

我对 ASP.NET 非常缺乏经验，但是在我发现的所有示例中，都没有使用这种方法。这是一种不好的做法，是否有我应该注意的“陷阱”？我可以看到，另一种选择是使用数据库。但我觉得这需要更多的努力，而且我猜是更多的资源（我认为我的消息“缓冲区”将占用大约 40kb 的内存，并节省不少访问数据库的次数）。

4

4 回答 4

8

Assuming that you make sure that the entire thing is thread-safe, that will work.

However, IIS can recycle your AppDomain at any time, so your queue may get blow away when you don't expect it.

于 2012-06-05T16:10:24.440 回答
3

即使 IIS 不会时不时地刷新和重新启动您的 AppDomain，但为此目的使用静态变量对我来说听起来像是一个臭名昭著的黑客攻击。

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

ASP.NET 应用程序状态概述

于 2012-06-05T16:13:34.710 回答
1

只要您的要求没有改变，并且您可以随机丢失服务器端的所有消息，这完全没问题。

我会稍微重构代码以提供“消息存储”接口以简化代码测试（如果您决定使其更复杂/持久/多用户在未来有潜在的好处）。

静态存储方法（或 HttpApplicationState）的优点：

  • 消息的服务器端存储没有问题 - 更少的隐私问题。没有什么是永远存储的，所以你可以说任何你想说的。
  • 极其简单的实现。
  • 非常适合 IM/电话交谈。
  • 在单服务器情况下不太可能出现性能问题

缺点：

  • 消息可能会丢失。可以通过在客户端存储历史来缓解（即在同一网页上使用 AJAX 查询检索消息）
  • 如果涉及更多用户/或应用程序与其他代码共享时数据敏感，则需要更加小心，因为每个人都可以看到静态数据。与任何其他存储也没有太大区别。
  • 不能直接迁移到多服务器/网园场景。2 人聊天服务器真的不太可能出现问题。
于 2012-06-05T16:36:07.877 回答
1

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

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

请注意讨论中的一个关键点：

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

于 2012-06-05T16:17:34.230 回答