Как совместить использование API членства с данными, относящимися к собственному приложению?

Разрабатывая новое приложение в asp.net 4, я должен решить, как использовать API членства в MS SQL вместе с моими собственными данными в базе данных MS SQL. Во-первых, мне нужно хранить данные профиля пользователя и получать к ним доступ более гибким образом, чем это поддерживает поставщик профилей. Во-вторых, я хотел бы связать другую информацию, связанную с пользователем (например, заказы).

Независимо от того, где вы храните свои таблицы aspnetdb (в отдельной базе данных или в той же базе данных, что и ваши данные), проблема заключается в том, как поддерживать синхронизацию данных.

После исследования я вижу следующие подходящие варианты:
1. UserId внешнего ключа от asp_Users (предлагается в это руководство).
2. Без внешнего ключа - используйте транзакции (рекомендуется здесь).
3. Без внешнего ключа - используйте настраиваемый AccountController (какой бы он ни был, рекомендуется здесь).
4. Дополнительная таблица, которая связывает пользовательский идентификатор членства (uid) с пользовательским идентификатором пользователя (int).
5. ...

С одной стороны, мне нравится первое решение, поскольку оно довольно простое и предлагается в официальном руководстве asp.net.

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

Итак, как лучше всего подойти к этому? Кроме того, как будет выглядеть реализация? Достаточно ли использовать только дополнительный код ADO.NET или LINQ и т. Д., Или стоит реализовать собственный поставщик членства и / или профиля?

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




Ответы (2)


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

Я успешно использовал вариант 4 в своем текущем приложении. Я создал таблицу aspnet_UserID с idUser int в качестве первичного ключа и fiUser (GUID aspnet_Users) в качестве внешнего ключа. Вот модель:

Модель данных

(Примечание: User - это стандартная aspnet_Users таблица, созданная с помощью aspnet_regsql.exe и aspnet_UserId моя настраиваемая таблица, которая отображает каждый Guid с моим int-ID)

Теперь я сохраняю только свой idUser как FK во всех связанных таблицах (например, в вашей таблице заказов). Это имеет то преимущество, что меньше места для хранения и более читабельные идентификаторы пользователя (я никогда не мог вспомнить GUID). Может быть, эта «таблица-обертка» несколько более отделена, но это не было моим основным намерением.

Вы можете изменить правило удаления для своих внешних ключей, если хотите контролировать поведение. Установите значение Cascade, если вы, например, хотите удалить все заказы, которые были заказаны пользователем, которого вы удаляете, или установите для него значение no Action, если вы хотите сохранить этот заказ.

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

person Tim Schmelter    schedule 30.06.2011
comment
Спасибо за ответ, 4-й вариант выглядит очень интересно. Таким образом, вы думаете, что поставщик членства в SQL (+ немного кода доступа к пользовательским данным) достаточно для этого сценария, и необходимость реализации настраиваемого поставщика профиля зависит от < / b> о моих конкретных требованиях к данным профиля, правильно ли я понял? - person Kirill; 01.07.2011
comment
@Kirill: насколько я могу судить, не зная ваших точных требований, да. - person Tim Schmelter; 01.07.2011

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

См. Этот образец MSDn (schema, code) для написания настраиваемого поставщика - в этом примере для доступа к базе данных используется OLEDB. Еще один пример - здесь - он использует активный каталог в качестве хранилища.

person VinayC    schedule 30.06.2011