ASP.NET Custom Membership Provider для очень больших приложений - PullRequest
9 голосов
/ 14 ноября 2010

Я должен придумать решение для членства для очень большого сайта.Сайт будет построен с использованием ASP.NET MVC 2 и базы данных MS SQL2008.

Текущий поставщик членства выглядит БОЛЬШИМ излишним, слишком много функций.

Все, что я хочу сохранитьэто электронная почта / пароль и основная информация профиля, такая как Имя / Фамилия, Номер телефона.Мне понадобятся только две роли: администраторы и пользователи.

Каковы ваши рекомендации по этому сценарию, учитывая, что могут быть зарегистрированы миллионы пользователей?Что использует StackOverflow?

В прошлом я много использовал существующий API-членство и расширил его для хранения дополнительной информации и т. Д. Но есть такие таблицы, как

aspnet_Applications
aspnet_Paths
aspnet_SchemaVersions
aspnet_WebEvent_Events
aspnet_PersonalizationAllUsers
aspnet_PersonalizationPerUser

, которыечрезвычайно излишним, и я никогда не нашел применения для.

Редактировать Просто чтобы прояснить некоторые другие избыточности после ответа @ drachenstern, есть также дополнительные столбцы, которые я не использую в таблице Membership / Users, но которые добавили бы к полезной нагрузке каждого оператора select / insert.

  1. MobilePIN
  2. PasswordQuestion / PasswordAnswer (я сделаю восстановление пароля по электронной почте)
  3. IsApproved (пользователь всегда будет утвержден)
  4. Комментарий
  5. MobileAlias ​​
  6. Имя пользователя / LoweredUsername (или электронная почта / LoweredEmail) [электронная почта - это имя пользователя, поэтому нужно только 1 из них]

Более того, я слышал, что GUID не так уж и быстр, и я бы предпочел иметь вместо него целые числа (как это делает Facebook), которые также были бы публично представлены.

Как мне поступитьсоздание собственного провайдера членства , повторное использование некоторых из API членства (проверка, шифрование пароля, cookie для входа в систему и т. д.) , но только с таблицами, которые соответствуют моимтребования?

Ссылки на статьи и существующие реализации приветствуются, мои поиски в Google дали несколько очень простых примеров.

Заранее спасибоMarko

Ответы [ 3 ]

13 голосов
/ 14 ноября 2010

@ Марко Я, конечно, могу понять, что стандартная система членства может содержать больше функций, чем вам нужно, но правда в том, что это действительно не имеет значения.Есть части системы членства, которые вы не собираетесь использовать, точно так же, как есть части .Net, которые вы не собираетесь использовать..Net может сделать множество вещей, которые вы никогда и никогда не будете использовать, но вы не собираетесь проходить через .Net и лишать себя такой функциональности?Конечно, нет.Вы должны сосредоточиться на вещах, которые важны для того, что вы пытаетесь достичь, и работать оттуда.Не попадитесь на паралич анализа.Вы будете тратить свое время, крутить свои колеса и не получите ничего лучшего, чем то, что уже было создано для вас.Теперь Microsoft иногда ошибается, но многие вещи делают правильно.Вам не нужно охватывать все, что они делают для достижения ваших целей - вам просто нужно понять, что важно для ваших нужд.

Что касается Guids и int как первичных ключей, позвольте мне кое-что объяснить.Существует принципиальная разница между первичным ключом и кластеризованным индексом.Вы можете добавить первичный ключ И кластерный индекс для столбцов, которые не являются частью первичного ключа!Это означает, что, если более важно упорядочить данные по имени (или какому-либо другому), вы можете настроить кластерный индекс так, чтобы он точно отражал то, что вам нужно, без его влияния на ваш первичный ключ.Позвольте мне сказать это по-другому - первичный ключ и кластерный индекс НЕ являются одним и тем же.Я написал сообщение в блоге о том, как добавить кластерный индекс, а затем первичный ключ к вашим таблицам.Кластерный индекс физически упорядочит строки таблицы так, как вам нужно, а первичный ключ обеспечит необходимую вам целостность.Взгляните на мой пост в блоге, чтобы узнать, как именно вы можете это сделать.

Вот ссылка - http://iamdotnetcrazy.blogspot.com/2010/09/primary-keys-do-not-or-should-not-equal.html.

Это действительно просто, вы просто добавляете кластерный индекс FIRST, а затем добавляете первичный ключ SECOND.Это должно быть сделано в таком порядке, иначе вы не сможете это сделать.Это предполагает, конечно, что вы используете Sql Server.Большинство людей не понимают этого, потому что SQL Server по умолчанию создаст кластерный индекс для вашего первичного ключа, но все, что вам нужно сделать, это сначала добавить кластерный индекс, а затем добавить первичный ключ, и все будет хорошо.Использование ints в качестве первичного ключа может стать ОЧЕНЬ проблематичным по мере масштабирования вашей базы данных и серверной системы.Я бы предложил использовать Guids и добавить кластеризованный индекс, чтобы отразить то, как вам на самом деле нужны ваши данные.

Итак, в заключение, я просто хочу сказать вам, чтобы вы создали что-то великое и не увязали в поверхностных деталях, которые не дадут вам достаточного прироста производительности, чтобы действительно иметь значение.Жизнь слишком коротка.Кроме того, помните, что ваша система может работать так же быстро, как и ее самый медленный фрагмент кода.Поэтому убедитесь, что вы смотрите на вещи, которые на самом деле занимают много времени, и заботитесь о них.

И еще одна дополнительная вещь.Вы не можете принимать все, что вы видите в Интернете, за чистую монету.Технология меняется со временем.Иногда вы можете просмотреть ответ на вопрос, который кто-то написал давным-давно, который больше не актуален сегодня.Кроме того, люди ответят на вопросы и предоставят вам информацию, не проверив на самом деле то, что они говорят, чтобы увидеть, правда это или нет.Лучшее, что вы можете сделать для своего приложения, - это действительно хорошо его протестировать.Если вы используете ASP.Net MVC, вы можете сделать это в своих тестах.Одна вещь, которую вы можете сделать, это добавить цикл for, который добавит пользователей в ваше приложение в вашем тесте, а затем протестировать его.Это одна идея.Есть и другие способы.Вам просто нужно приложить немного усилий, чтобы хорошо спроектировать свои тесты или, по крайней мере, достаточно хорошо для своих целей.

Удачи вам!

5 голосов
/ 14 ноября 2010

Текущий провайдер членства кажется БОЛЬШИМ излишним, слишком много функциональности.

Все, что я хочу сохранить, это адрес электронной почты / пароль и базовая информация профиля, такая как Имя / Фамилия, Номер телефона. Мне понадобятся только две роли: администраторы и пользователи.

Тогда просто используйте эту часть. Он не будет использовать части, которые вы не используете, и вы можете обнаружить, что вам понадобятся эти другие части в будущем. Классы уже присутствуют в .NET Framework, поэтому вам не нужно предоставлять никаких лицензий или чего-либо еще.

Размер базы данных достаточно мал, и если вы делаете так, как я, и оставляете aspnetdb себе, то вы ничего не берете из других ваших баз данных.

Есть ли у вас веские основания использовать сторонний компонент НАД тем, что уже есть в платформе?


EDIT

есть также дополнительные столбцы, которые я не имеет смысла в Членство / Таблица пользователей, но которая добавил бы к полезной нагрузке каждого выберите / вставьте операторы.

MobilePIN PasswordQuestion / PasswordAnswer (Я буду сделать восстановление пароля по электронной почте) IsApproved (пользователь всегда будет одобренный) Комментарий MobileAlias Имя пользователя / LoweredUsername (или Email / LoweredEmail) [электронная почта имя пользователя, поэтому нужно только 1 из них]

Звучит так, будто вы пытаетесь микрооптимизировать . Передача пустых строк практически бесплатна (хорошо, она есть, но вы должны зарегистрироваться, чтобы узнать, сколько это будет стоить. Это будет НЕ ТОЛЬКО для каждого пользователя). Мы уже обычно не используем все эти поля в наших приложениях, но мы используем систему членства без ощутимого вредного воздействия.

Кроме того, я слышал, что у Guid не все так быстро, и вместо этого предпочел бы иметь целые числа (как в Facebook), которые также были бы публично раскрыты.

Я слышал, что монстр печенья любит куки. Опять же, без профилирования, вы не знаете, если это вредно. Обычно люди используют идентификаторы GUID, потому что они хотят, чтобы он был абсолютно (в некоторой степени абсолютным) уникальным, независимо от того, когда он был создан. Стоимость его генерации ОДИН РАЗ для одного пользователя не так уж велика. Не тогда, когда вы уже создаете им новую учетную запись.


Поскольку вы абсолютно настроены на создание MembershipProvider с нуля, вот несколько ссылок:

http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx

http://www.4guysfromrolla.com/articles/120705-1.aspx

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx

http://www.amazon.com/ASP-NET-3-5-Unleashed-Stephen-Walther/dp/0672330113

Стивен Вальтер подробно расскажет об этом в своей книге, и это хороший пример для вас, чтобы вы были как есть.

3 голосов
/ 14 ноября 2010

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

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

...