ASP.net MVC 消除重复的数据调用
我有一个与 ASP.net 身份验证一起使用的 asp.net mvc 站点。我有一个 UserInformation 表，它还存储每个用户的额外信息。几乎在每个页面上，我都会调用数据库至少一次提取当前用户的用户信息记录。
我认为所有这些对相同信息的重复数据调用都太过分了。无论如何我可以减少这些吗？缓存？存储用户信息记录以供将来使用等？
我确信我不是第一个遇到这个问题的人，所以我不想重新发明轮子。
提前致谢
Ive got a asp.net mvc site that works with ASP.net Authentication. I have a UserInformation table which stores extra information on each user aswell. On pretty much every page i am calling to the database to pull the UserInformation record for the current user at least once.
Im thinking all these repeated data calls for the same information has to be overkill. Is there anyway i can cut these down? Caching? Storing the userinformation record for future use etc etc?
Im sure im not the first person to come across this issue, so i didnt want to reinvent the wheel.
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以使用自定义 IIdentity 和 IPrincipal。这是一篇很好的文章，描述了如何实现这一目标（有趣的部分发生在
btnAuthenticate_Click方法中，该方法在 ASP.NE MVC 应用程序中将是身份验证控制器操作，此处发出带有自定义数据的身份验证票证）。在此示例中，我们的想法是手动创建身份验证票证，并使用userData属性来存储附加信息。如果您有大量数据，这可能不适合您的情况，因为这些数据存储在 cookie 中。但您可以将其存储在会话或缓存等其他位置，而不是使用userData。您还可以编写自定义[Authorize]< /code>属性来处理自定义主体（与本文中的Application_AuthenticateRequest方法相对应的部分应放入此自定义授权过滤器中，以便重新构造用户）。You could use a custom IIdentity and IPrincipal. Here's a nice article describing how to achieve this (the interesting part is happening in the
btnAuthenticate_Clickmethod which in an ASP.NE MVC application would be the authenticate controller action, here is emitted the authentication ticket with custom data). In this example the idea is that the authentication ticket is manually created and theuserDataproperty is used to store additional information. This might not be appropriate for your case if you have lots of data because this is stored in a cookie. But instead of using theuserDatayou could store it somewhere else like Session or Cache. You could also write a custom[Authorize]attribute to deal with the custom principal (the part that corresponds to theApplication_AuthenticateRequestmethod in the article should go in this custom authorization filter in order to reconstruct the user back).