Прежде чем приступать к изучению подробностей реализации пользовательских поставщиков, важно понять, зачем вообще может понадобиться собственного поставщика Membership. Вот несколько распространенных причин:

• Вы хотите использовать существующую базу данных пользователей и ролей, которая основана на схеме, отличной от стандарта ASP.NET.
• Вы хотите использовать базу данных, отличную от Microsoft SQL Server.
• Вы хотите использовать необычное хранилище данных (такое, как XML-файл, Web-служба или служба Active Directory.
• Вы хотите реализовать дополнительную логику аутентификации. Хорошим примером этого могут быть многие реализации правительственных Web-сайтов, где пользователи должны аутентифицироваться, указывая три значения: имя, идентификатор подписи (Subscription ID) и пароль.

Если вы просто хотите хранить свою собственную информацию в дополнение к информации, хранимой реализацией по умолчанию, то мы не советуем для этого разрабатывать собственного поставщика. Поскольку Membership API предоставляет доступ к ключу, уникально идентифицирующему пользователя в хранилище, мы советуем добавить собственные таблицы для хранения дополнительной информации и информации соединения через уникальный ключ пользователя с записями пользователей в хранилище стандартного поставщика Membership. Альтернативно вы можете реализовать профили пользователей для хранения этих дополнительных свойств. Это намного проще, чем реализовать собственного поставщика для добавления нескольких дополнительных значений.

Изнутри приложения вы можете получить доступ к уникальному ключу пользователя через свойство ProviderUserKey класса MembershipUser. В настоящей главе вы узнаете о том, как распространяется уникальный ключ на свойства ProviderUserKey класса MembershipUser.

Базовые шаги создания
пользовательского поставщика

Теперь вы узнаете, как реализовать собственного поставщика для служб Membership и Roles. Создание пользовательского поставщика включает следующие шаги:

1. Проектирование и создание лежащего в основе хранилища данных.
2. Создание служебных классов для доступа к хранилищу.
3. Создание класса-наследника MembershipProvider.
4. Создание класса-наследника RoleProvider.
5. Создание тестового приложения для испытания поставщиков.
6. Конфигурирование пользовательских поставщиков в вашем тестовом приложении.
7. Использование новых пользовательских поставщиков в рабочем приложении.

предыдущая    следующая страница    вначало главы    оглавление

1026