Архитектура пользовательских поставщиков

184

Ранее вы узнали все необходимые детали аутентификации и авторизации пользователей в ASP.NET с применением механизма аутентификации с помощью форм. Вам известно, что при аутентификации с помощью форм вы сами отвечаете за управление пользователями (и ролями, если нужна аутентификация на основе ролей) в специальном хранилище.

К счастью, ASP.NET включает в себя интерфейсы Membership API и Roles API, которые предоставляют готовую платформу управления пользователями и ролями. Эту платформу можно расширить с помощью механизма поставщиков, которые реализуют доступ к лежащему в основе хранилищу данных. Ранее были использованы поставщики по умолчанию для SQL Server, которые поставляются вместе с ASP.NET.

Заменить реализацию по умолчанию, работающую с SQL Server, можно за счет построения собственных поставщиков членства и ролей. Это предоставляет возможность замены лежащего в основе хранилища информации о пользователях и ролях, не затрагивая веб-приложения.

Ранее вы узнали множество подробностей об интегрированных службах членства и ролей. Эти службы предоставляют в ваше распоряжение готовые решения для управления пользователями и ролями с аутентификацией с помощью форм. Как объяснялось, эта модель может быть расширена за счет так называемых пользовательских поставщиков, как показано на рисунке ниже:

Membership API и Roles API

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

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

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

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

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

Пройди тесты
Лучший чат для C# программистов