不要使用基本控制器。您可以使用操作过滤器完成此操作。这将为您提供拦截点,以检查他们是否已登录,是否选择了帐户,甚至将他们重定向到错误或帐户选择页面。您所要做的就是filterContext.Result
在操作过滤器的OnActionExecuting
方法中进行设置,以防止请求通过。在操作期间,您可以完全访问会话、临时数据、cookie 和整个 HttpContext,就像在控制器中一样。您还可以使用过滤器属性过滤器提供程序属性注入依赖项,这样就可以为您提供所需的任何数据访问权限。
就数据建模而言,我对 Linq to SQL 不太熟悉,但我认为正常的一对多应该可以解决问题:
User (1) <-------> (0..*) Account
public class User
{
public virtual ICollection<Account> Accounts { get; protected internal set; }
}
public class Account
{
public int UserId { get; protected internal set; }
public virtual User User { get; protected internal set; }
}
更新:对不起,我误解了你所说的“商店”的意思。在 MVC 中,只有几种方法可以存储它 - Session、Cookie 和 Cache(以及 TempData,它只是短期会话)是最流行的选择。我的选择将取决于。Session 可能是最简单的,但是如果你部署到带有负载均衡器的服务器场,你需要考虑如果用户的 session 跳过物理机会发生什么。会话会保持不变吗?
正如杰里米所说,还有饼干。这里不用担心负载平衡,但语义比会话更难处理。例如,您必须先发送重定向以写入 cookie,然后才能读取它,而且我从不喜欢您必须添加过期 cookie 才能删除它的事实。由于此数据是您安全的一部分,您可能还想加密 cookie 值。
如果您使用缓存,则数据很可能最终仍会存在于内存中的某个位置,例如会话(除非您使用的是 SQL 会话提供程序)。缓存可能是我最后的选择,因为我们使用 Azure,而且它们的缓存不支持很多出色的 MVC 功能。您也有同样的问题,负载均衡器将用户移动到集群中的另一台机器,数据可能需要重新缓存。
无论哪种方式,您仍然应该为此使用操作过滤器,而不是基本的 Controller 类。