Как совместить использование Membership API с собственными данными приложения?

Question

Разработка нового приложения на 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 и т. Д., Или стоит внедрить пользовательский членство и / или поставщика профилей?

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

Answer 1

Первый - самый простой подход. Добавьте 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). Может быть, он несколько более отделен этим «столом-оберткой», но это не было моим главным намерением.

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

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

Answer 2

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

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