Я обнаружил, что самый простой способ - использовать MembershipSystem, но максимально избегать ProfileSystem.
Я использую Usertable, который имеет столбец UserID, который сопоставляется с UniqueID ProileSystem. Вы видите, что в системах есть перерыв: с одной стороны есть профиль, а с другой - мой пользователь.
Здесь и там возникает проблема:
- Вы создаете членство пользователя и запись профиля, а после нее вы создаете запись в таблице пользователей. Нет никакой возможности иметь транзакцию, которая охватывает обе операции.
- Пользователь меняет свой E-Mail. Это должно быть сделано для системы Mebrships и для пользователя таблицы
Вы можете начать реализацию свойств с помощью пользовательского ProfileProvider. Это легко, и вы даже можете использовать свою собственную таблицу пользователей. Но в моем случае я обнаружил, что это плохо: большая часть ProfileSystem проникла в мое приложение. Я начал с таблицы пользователя, затем мне пришлось подумать о таблице адресов, таблице заказов ....
В конце я увидел, что где-то будет перерыв, поэтому решил сделать это как можно раньше. Ваша ситуация может быть другой, и ProfileSystem может быть полезна в некоторых ситуациях, но если вы начнете внедрять большую часть своего приложения в провайдере пользовательских профилей, я подумаю еще раз.
Итак, мое предложение:
Используйте MembershipSsytem и ProfileSystem для создания учетной записи и получения идентификатора пользователя. Затем используйте этот идентификатор в своем бэкэнде.