我可以在哪里使用 ASP.NET MVC 和 MembershipProvider 保留用户所属的公司？
当用户登录到我的 ASP.NET MVC 应用程序时，我需要保留该用户所属的公司。 他们所属的公司将确定他们的查询来自哪个数据库，因此对我来说，在他们登录后立即查询他们的公司并保留它很重要，这样我就不必再次执行此查找。
我应该在哪里/如何存储此公司 ID？ 会议？ 有什么方法可以自定义 MembershipProvider 来允许我在 User 对象中保留此信息？
处理这个问题的最佳方法是什么？ 从字面上看，此后我所做的每个查询都将很大程度上取决于该公司 ID，因此保留该信息非常重要。
When a user logs on to my ASP.NET MVC application I need to persist what company that user belongs to. The company they belong to will determine what database ~all~ their queries come from so it is important for me to query for their company as soon as they log in and persist it so I don't have to perform this lookup again.
Where/How should I store this Company ID? Session? Some way to customize a MembershipProvider that would allow me to retain this information in a User object?
What would be the best way to handle this? Literally, every query I do after that will wildly depend on that company ID so it is important that I retain that information.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用 ASP.NET 的配置文件属性，但您需要为它们创建自己的处理程序。 查看 Seventh Element 对此问题的回答了解如何开始的想法。
You could use ASP.NET's Profile Properties, but you need to create your own handler for them. Check out Seventh Element's answer to this question for ideas on how to get started.
您可以编写自己的身份验证模块来扩展FormsAuthentication 并将公司存储在 IPrincipal 中。
然后你就可以像 一样执行 User.Identity.Company用户.身份.名称。
与将公司放入诸如缓存或会话之类的现有存储桶中相比，这是更多的前期工作，但一旦您将所有内容都连接起来，它就可以让您编写一些相当轻松的代码。
You could write your own Auth module to extend FormsAuthentication and store the company in the IPrincipal.
Then you get to do User.Identity.Company just like User.Identity.Name.
This is more up-front work than sticking the company in an already-existing bucket like Cache or Session, but it lets you write some pretty effortless code once you have everything wired up.
我会将其放入会话中，因为在您的情况下，使用配置文件意味着每个数据库调用需要 1 次额外的数据库往返。
如果您在每个操作方法中都访问该配置文件，那么您当然应该使用它。
I would put it into session, because in your case using the Profile means 1 additional roundtrip to DB for every DB call.
If you access the profile anyway in every actionmethod then you should use it offcourse.