C# 在MVC中（服务器）交互期间检查用户的状态

我有一个思想上的问题，我不确定我已经构建的东西是否可以更有效地完成，所以这就是为什么我要在这里分享我的“问题”。（说得很清楚，我所做的一切都很有效，我只是想提高效率）

我有一个用MVC和SQL制作的webapp，它有一个用户登录系统等。 用户有一个状态，即枚举，可以是活动的、被阻止的等，并存储在数据库中（与其他用户数据一起）

在我的webapp中，我定制了一个AuthorizeAttr。用于在每次呼叫时授权用户（作为全局筛选器应用）

但是，“正常”身份验证基于cookie，当我更改数据库中的用户状态时，cookie不会更改。例如，用户可以取消激活同一组中的另一个用户（作为管理员时）。这些数据库更改不会立即生效，因为默认情况下，授权仅验证cookie，并且cookie基于登录时的状态

为了解决这个问题，我在authorizationAttr中添加了一些额外的逻辑，它在每次请求时调用数据库以获取当前用户状态（枚举），然后简单地检查是否允许用户继续，或者是否需要重定向

在每次请求时调用数据库（即使仅针对1个枚举）似乎对服务器/db有点费劲，尤其是当webapp越来越受欢迎（=大量用户）时

我想到的一个想法是将枚举缓存在会话缓存中，但在短时间内（如60秒），这将节省一些数据库调用，但显然，用户在停用webapp后最多可以使用60秒

我可能会错误地认为这些数据库调用实际上很累人

---

有改进的想法吗？

您是否考虑过使用ADO.NET数据集来满足您的需求？如果您没有多个前端，则可以将登录状态最初读取到数据集中。可以对此进行所有读/写操作，您可以稍后将更改保存到实际数据库中。如果您有多个前端，是否可以将一个组的所有读/写/修改操作限制为一个前端实例？因为我想在这种情况下你也可以使用数据集方法。

你怎么知道检查每个请求的状态太昂贵了？您是否衡量了检查数据库中用户状态的性能成本？您是否创建了自定义缓存而没有实际衡量简单解决方案的成本？你是否像hibernate一样使用ORM？它们内置了二级缓存，因此通常不会往返到数据库

我认为坚持接吻原则比为客户定制解决方案更好。即使您的数据库将成为瓶颈，通常一次购买额外的硬件也比多年维护过于复杂的解决方案要便宜

---

如果您的应用程序增长了，那么您首先要抛弃的就是关系数据库

此外，我现在正在使用nhibernate，我认为按照您的方式进行操作在这一点上可能会有太多的变化，但有趣的想法是：）thxI还没有做任何性能测试，我使用的是Nhibernate，我知道它们的缓存也可以减轻数据库的压力。我想正如你所建议的，我现在会保持简单，当我开始注意到实际问题时，我会更深入地挖掘。正如我所说，目前还没有实际的性能问题，这更多的是出于好奇而非必要。