Является ли провайдер пользовательского членства тем, за чем стоит следовать? - PullRequest
0 голосов
/ 08 декабря 2011

После долгих попыток получить ответ на мой вопрос "Должен ли я написать собственную реализацию MembershipProvider или создать собственную систему?" поэтому я решил, что не так уж и плохо идти по пути MembershipProvider и начать писать свой членский провайдер. Но в то время я чувствую некоторые проблемы.

Например, в моей системе нет имен пользователей. Письма являются именами пользователей. Поэтому метод CreateUser должен выглядеть следующим образом:

public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
{
    bool userExists = GetUser(email);
    if (userExists) {
        status = MembershipCreateStatus.DuplicateEmail;
        return null;
    }
    bool? tryExists = regTryExists(email);
    if (tryExists.HasValue && tryExists.Value && !userExists)
    {
        UserRepository.CreateUser(email, password);
        status = MembershipCreateStatus.Success;
        return GetUser(email);
    }

    return null;
}

Кроме того, мне не нужны методы GetUserNameByEmail, FindUsersByName:

public override string GetUserNameByEmail(string email)
{
    return email;
}  

public override MembershipUserCollection FindUsersByName(string usernameToMatch, int pageIndex, int pageSize, out int totalRecords)
{
    throw new NotImplementedException();
}

Так что здесь мне не нужны username, passwordQuestion, passwordAnswer, isApproved аргументы.

Также в моей системе нет пользовательских вопросов, поэтому мне не нужны такие методы, как

public override bool ChangePasswordQuestionAndAnswer(string username, string password, string newPasswordQuestion, string newPasswordAnswer)
{
    return false;
}
public override string ResetPassword(string username, string answer)
{
    throw new NotImplementedException();
}

И это только часть ненужной и громоздкой системы членства. Это не так реально, как я хочу.

Итак, вопрос в том, стоит ли идти с MembershipProvider? Не могли бы вы привести меня? Есть ли хорошие преимущества для MembershipSystem, которые делают его действительно ценностной системой?

Ответы [ 5 ]

4 голосов
/ 08 декабря 2011

Использование MembershipProvider по сути сводится к решению «построить или купить», которое должен принять любой разработчик (или dev mgr): собрать его с нуля, или купить в продаже (или в этом случае использовать предварительно существующий инструмент).

Имея это в виду ... по общему признанию, MembershipProvider не идеален - он немного неуклюж, и, вероятно, имеет слишком много (или слишком мало) того, что вам нужно - но это 85% пути для большинство реализаций. И, как говорят другие, создание собственной системы аутентификации с нуля просто не стоит ни времени, ни усилий. Это решенная проблема ; Используй энергию своего развития для решения более насущных и актуальных проблем бизнеса, а не изобретай велосипед!

Запомните эту аксиому: если вы не можете получить прямое конкурентное преимущество от разработки чего-либо с нуля, вам (как правило) лучше использовать существующий инструмент для работы (покупайте, а не строите).

1 голос
/ 08 декабря 2011

Некоторые преимущества API поставщика членства в ASP.NET:

  • Вам не нужно изобретать велосипед.Новички в вашем проекте будут знакомы с хорошо известным API.
  • Уже есть доступные реализации (в основном SQL Server, Active Directory), которые можно использовать повторно или начать с.
  • Этовизуально интегрированный с ASP.NET (элементы управления входом в систему и т. д.)
  • Вы можете использовать встроенный инструмент администрирования ASP.NET для создания пользователей и ролей (на самом деле это хороший способ убедиться, что ваш провайдер работает нормально,как это должно работать с инструментом)
  • Он может быть интегрирован с классами идентификации / принципала .NET (не только ASP.NET) и может использоваться для поддержки системы PermissionAttribute (с соответствующим поставщиком ролей).,Хотя технически он находится в System.Web.dll, на самом деле его можно использовать в не-веб-системах.
  • И последнее, но довольно интересное: вы также можете использовать поставщиков членства ASP.NET в WCF.услуги
0 голосов
/ 08 декабря 2011

Сначала я использовал нестандартный провайдер, но теперь полностью отключен.

Я придерживался только одного принципа: когда нужно блокировать пользователя, как хэшировать пароль и т. Д.

Я работал с пользовательским провайдером до тех пор, пока мне не потребовалась поддержка нескольких клиентов с различными базами данных.И последней каплей была моя попытка модульного тестирования службы WCF, которая использовала членство провайдера.Теперь у меня есть служба членства и жизнь хорошая.У меня все еще есть структура данных, почти идентичная оригинальной, но в .NET я использую свой код

0 голосов
/ 08 декабря 2011

По умолчанию MembershipProvider делает все, что вам нужно.
Поэтому я бы определенно рекомендовал создать класс UserBusiness, который охватывает MembershipProvider и предоставляет только те функции, которые вы используете.

Это упрощает использование замечательных функций MembershipProvider, а также упрощает интерфейс для ваших нужд.

0 голосов
/ 08 декабря 2011

Ну, MembershipProvider действительно полезен.Вся инфраструктура безопасности ASP.Net построена вокруг него.Многие элементы управления могут напрямую взаимодействовать с такой инфраструктурой, как Login, LoginStatus.Так что у него есть преимущество.
Но он также имеет свою долю проблем из-за своего толстого интерфейса.Это нарушает принцип сегрегации интерфейса и, следовательно, является немного громоздким в использовании.Я считаю, что преимущества перевешивают штраф, который мы платим здесь.Так что, пока есть простые обходные пути, это не наносит вреда.
Создание собственной инфраструктуры безопасности также не является тривиальной задачей.

...