ASP.NET SQL 配置文件提供程序 - ProfileBase.Create() 方法是否访问数据库?

发布于 2024-07-27 19:14:38 字数 409 浏览 8 评论 0原文

我正在使用 SQLMemebershipProvider 并使用配置文件。 我有一个名为 UserProfile 的自定义类,它继承自 ProfileBase 类,我使用它来设置“FullName”等自定义属性。 我想循环访问数据库中的所有用户并访问他们的配置文件属性。 在每次迭代中,我都会调用 ProfileBase.Create() 来获取新的配置文件,然后访问属性。

在我看来,每次调用 ProfileBase.Create() 时,它都会访问我的 SQL 数据库。 但我只是在寻找对此的确认。 那么,有谁知道这是否每次都会击中数据库?

更好的是,是否有人有更好的解决方案来帮助我一次调用数据库来获取所有用户的自定义配置文件属性?

我知道我可以编写自己的存储过程,但我想知道是否有一种内置于会员资格提供程序中的方法。

I am working with the SQLMemebershipProvider and using Profiles. I have a custom class called UserProfile that inherits from the ProfileBase class and I use this to set custom properties like "FullName". I am wanting to loop through all the users in the database and get access to their profile properties. On each iteration I am calling ProfileBase.Create() to get a new profile and then access the properties.

It looks to me like every time ProfileBase.Create() is called it hits my SQL database. But I am just looking for confirmation of this. So, does anyone know if this does in fact hit the DB each time?

And better yet, does anyone have a better solution of how I could make one call to the DB to get all users with their custom profile attributes?

I know I could write my own stored proc, but I am wondering if there is a way built in to the Membership Provider.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

日记撕了你也走了 2024-08-03 19:14:38

迈克,我相信你所观察到的是真的。 我正在使用使用 Azure TableStorage 作为数据存储的 ProfileProvider。 我想从数据库中获取用户配置文件列表,并将它们与会员提供商的信息合并。
我花了一些时间才意识到,使用用户名作为参数调用 ProfileBase.Create() 会执行对 TableStorage 的查找,并实际上检索与该用户名关联的数据。 就我而言,调用此方法 Create() 会产生误导,我希望使用 Load()Get()
目前我的代码如下所示:

    public IEnumerable<AggregatedUser> GetAllAggregatedUsers()
    {
        ProfileInfoCollection allProfiles = this.GetAllUsersCore(
             ProfileManager.GetAllProfiles(ProfileAuthenticationOption.All)
        );

        //AggregatedUser is simply a custom Class that holds all the properties (Email, FirstName) that are being used
        var allUsers = new List<AggregatedUser>();

        AggregatedUser currentUser = null;
        MembershipUser currentMember = null;
        foreach (ProfileInfo profile in allProfiles)
        {
            currentUser = null;
            // Fetch profile information from profile store
            ProfileBase webProfile = ProfileBase.Create(profile.UserName);
            // Fetch core information from membership store
            currentMember = Membership.FindUsersByName(profile.UserName)[profile.UserName];
            if (currentMember == null)
                continue;

            currentUser = new AggregatedUser();
            currentUser.Email = currentMember.Email;
            currentUser.FirstName = GetStringValue(webProfile, "FirstName");
            currentUser.LastName = GetStringValue(webProfile, "LastName");
            currentUser.Roles = Roles.GetRolesForUser(profile.UserName);
            currentUser.Username = profile.UserName;
            allUsers.Add(currentUser);
        }

        return allUsers;
    }

    private String GetStringValue(ProfileBase profile, String valueName)
    {
        if (profile == null)
            return String.Empty;
        var propValue = profile.PropertyValues[valueName];
        if (propValue == null)
            return String.Empty;

        return propValue.PropertyValue as String;
    }

是否有更好(更直接、更高效)的方法来

  1. 从配置文件提供商检索所有自定义配置文件信息并将
  2. 它们与会员提供商信息合并以在管理员页面中显示它们?

我看过 Web Profile Builder 但在我看来,这仅为自定义提供设计时智能感知通过生成代理类来配置属性。

Mike, I believe what you observed is true. I am working with a ProfileProvider that uses Azure TableStorage as data store. I wanted to get a list of user profiles from database and merge them with information from membership provider.
It took some time until I realized that calling ProfileBase.Create() with a username as argument performs a lookup against TableStorage and actually retrieves the data associated with that username. As far as I'm concerned, calling this method Create() is misleading, I would expect Load() or Get().
Currently my code looks like this:

    public IEnumerable<AggregatedUser> GetAllAggregatedUsers()
    {
        ProfileInfoCollection allProfiles = this.GetAllUsersCore(
             ProfileManager.GetAllProfiles(ProfileAuthenticationOption.All)
        );

        //AggregatedUser is simply a custom Class that holds all the properties (Email, FirstName) that are being used
        var allUsers = new List<AggregatedUser>();

        AggregatedUser currentUser = null;
        MembershipUser currentMember = null;
        foreach (ProfileInfo profile in allProfiles)
        {
            currentUser = null;
            // Fetch profile information from profile store
            ProfileBase webProfile = ProfileBase.Create(profile.UserName);
            // Fetch core information from membership store
            currentMember = Membership.FindUsersByName(profile.UserName)[profile.UserName];
            if (currentMember == null)
                continue;

            currentUser = new AggregatedUser();
            currentUser.Email = currentMember.Email;
            currentUser.FirstName = GetStringValue(webProfile, "FirstName");
            currentUser.LastName = GetStringValue(webProfile, "LastName");
            currentUser.Roles = Roles.GetRolesForUser(profile.UserName);
            currentUser.Username = profile.UserName;
            allUsers.Add(currentUser);
        }

        return allUsers;
    }

    private String GetStringValue(ProfileBase profile, String valueName)
    {
        if (profile == null)
            return String.Empty;
        var propValue = profile.PropertyValues[valueName];
        if (propValue == null)
            return String.Empty;

        return propValue.PropertyValue as String;
    }

Is there a better (more straightforward, more performant) way to

  1. retrieve all the custom profile information from profile provider and
  2. merge them with membership provider info to show them e.g. in an administrator page?

I have had a look at Web Profile Builder but IMO this only provides design-time intellisense for custom profile properties by generating a proxy class.

输什么也不输骨气 2024-08-03 19:14:38

在调用 保存

Save方法写入修改
配置数据的属性值
来源。 配置文件提供者可以
减少活动量
仅执行更新的数据源
当 IsDirty 属性设置为
真的。 这是默认的情况
SqlProfileProvider。

You don't persist to the database until you call Save:

The Save method writes modified
profile property values to the data
source. The profile provider can
reduce the amount of activity at the
data source by performing updates only
when the IsDirty property is set to
true. This is the case for the default
SqlProfileProvider.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文