我的ASP.NET MVC 4项目使用EF5代码优先，并且一些域对象包含非持久计数器属性，这些属性根据传入请求进行更新。这些请求非常频繁，多个请求会话正在修改这些计数器的情况很可能。
我的问题是，是否有最佳实践，不一定与ASP.NET或EF相关，以处理这种情况？我认为（但我不确定）为了讨论起见，我们可以将域对象视为简单的POCO（它们是）。
编辑：根据要求，以下是实际情况：
该系统是订户和内容管理系统。对等服务器正在发出我的系统授权或拒绝的请求。授权请求导致对等服务器中的打开会话。在对等服务器中关闭会话时，它会发出通知会话已关闭的请求。
我的系统需要提供统计信息 - 例如，每个内容项目（一个域实体）的当前打开会话数 - 并提供实时数据以及每分钟，每小时，每日，每周等数字。
由于性能问题，无法通过查询数据库来提取这些数字，所以我决定在内存中实现基本计数器，每分钟将它们保存到数据库并按小时，每天等进行。来自那里的数据。
上述问题是由于每个对等服务器请求都更新了这些“计数器”。
我希望现在更清楚了。
答案 0 :(得分：1)
听起来你的场景仍然需要坚实的持久性策略。
您的计数器对象可以持久保存到HttpRuntime.Cache。
Dan Watson在这里写了一篇特别的文章：
http://www.dotnetguy.co.uk/post/2010/03/29/c-httpruntime-simple-cache/
请务必使用CacheItemPriority.NotRemovable确保在内存回收期间保持状态。缓存将保持在app域的范围内。您可以在缓存中检索和更新计数器（其线程安全！）并从大概是统计页面或其他选项查询其状态。但是，如果数据需要持续超出运行时范围，那么您已经使用的策略就足够了。
答案 1 :(得分：1)
实际上，在您没有足够的测试和分析工具信息之前，我认为您没有必要对性能保持警惕。
但是如果您正在使用EF，那么您就可以处理DataContext，这是Martin Fowler在他的书中描述的工作单元模式实现。这种模式的主要思想是减少请求数据库的数量并尽可能地在内存中操作数据，直到您不提交所有更改为止。所以我的简短建议只是以标准方式使用您的EF实体，但不是每次数据更新时都提交更改，而是使用一些间隔，例如在100次更改之后，在Session，Application session，Cache或者请求之间存储数据别的地方。你唯一应该关心的是你每次都使用正确的DataContext对象，不要忘记在你不再需要它时把它丢弃。