Класс членства вызывает неправильный метод в моем пользовательском провайдере?

Я разработал собственный поставщик членства и ролей. Класс System.Web.Security.Membership вызывает метод CreateUser, который я не реализовал (намеренно я хочу больше информации в моем MembershipUser).

Должен ли я вообще использовать класс Membership в этом сценарии?

Теперь я привожу тип к своему собственному провайдеру членства, чтобы использовать мой реализованный метод CreateUser, это правильный путь? Я чувствую себя немного потерянным, как мне справиться с этим?

((MyMembershipProviderBase)Membership.Provider).CreateUser(username, password, email, lastName, firstName, phoneNumber, out status);

Поставщик членства CreateUser-методы:

    public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
    {
        throw new NotImplementedException();
    }

    public MyMembershipUser CreateUser(
        string username, string password, string email, string lastName, string firstName,
        string phoneNumber, out MembershipCreateStatus status)
    {
        // implemented...
    }

*Редактировать

Отвечает на комментарий @elkdanger.

Это та оболочка, о которой вы говорите в своем комментарии?

Теперь класс Membership вызывает стандартный метод CreateUser, который перенаправляет на мою собственную реализацию, проблема в том, что я не могу установить дополнительную информацию для пользователя (имя, фамилия и номер телефона). Это способ пойти, а затем настроить дополнительную информацию из другого места (где я создаю своего пользователя)?

public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion,
        string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
    {
        return this.CreateUser(username, password, email, "", "", "", out status);
    }

    public MyMembershipUser CreateUser(
        string username, string password, string email, string lastName, string firstName,
        string phoneNumber, out MembershipCreateStatus status

        )
    {
        var args =
   new ValidatePasswordEventArgs(username, password, true);

        OnValidatingPassword(args);

        if (args.Cancel)
        {
            status = MembershipCreateStatus.InvalidPassword;
            return null;
        }


        if (RequiresUniqueEmail && GetUserNameByEmail(email) != "")
        {
            status = MembershipCreateStatus.DuplicateEmail;
            return null;
        }

        MembershipUser u = GetUser(username, false);

        if (u == null)
        {

            try
            {
                status = Repository.CreateUser(username, EncodePassword(password), email, lastName, firstName,
        phoneNumber);
            }
            catch
            {
                status = MembershipCreateStatus.ProviderError;
            }
            return (MyMembershipUser)GetUser(username, false);
        }
        else
        {
            status = MembershipCreateStatus.DuplicateUserName;
            return null;
        }
    }

person user579089    schedule 08.02.2011    source источник


Ответы (1)


Выполняя таким образом доступ к вашему конкретному экземпляру, вы почти полностью игнорируете точку системы членства Asp.Net. Идея состоит в том, что система работает с известным контрактом для управления своими пользовательскими данными, и когда вам приходится начинать кастинг таким образом, вы нарушаете этот контракт. Я понимаю, что это может быть небольшое изменение, но, тем не менее, это немного «запах».

На этом этапе вы можете также запустить свою собственную реализацию, потому что на самом деле разницы не будет, но вы сэкономите некоторое время, просто придерживаясь того, что у вас есть.

Если вы хотите немного почистить это, я бы вернулся к исходному методу CreateUser, который членство в Asp.Net дает вам для перегрузки, но создайте оболочку вокруг функциональности членства, которая обеспечивает все дополнительные детали, которые вам нужно передать. Если вы не можете этого сделать (возможно, потому, что вы используете элементы управления мастера создания пользователя по умолчанию, которые поставляются с Asp.Net), тогда я бы посоветовал вашим требованиям перерасти то, что обслуживает система членства Asp.Net, и вам лучше в долгосрочной перспективе разработать собственную систему, которая больше подходит для того, чего вы пытаетесь достичь.

Удачи!

person Steve Hobbs    schedule 09.02.2011
comment
Спасибо за комментарий! Я не знаю, полностью ли я понимаю, как должна быть реализована обертка, которую вы предлагаете, но я попробовал и обновил свой пост выше. - person user579089; 11.02.2011
comment
Я не использую элемент управления Create Wizard, я начал с нового решения MVC и работал над реализацией Providers. Цель состоит в том, чтобы иметь возможность использовать встроенную функциональность пользователей и ролей, но при этом иметь контроль над тем, как и какая информация о пользователях (и ролях) хранится в базе данных. - person user579089; 11.02.2011