Используя ASP.NET Поставщик Членства SQL, как я храню свои собственные данные в расчете на пользователя?
Я использую Поставщика Членства SQL ASP.NET. Так, существует aspnet_Users таблица, которая имеет детали каждого из моих пользователей. (На самом деле, aspnet_Membership таблица, кажется, содержит большинство фактических данных).
Я теперь хочу хранить некоторую информацию в расчете на пользователя в своей базе данных, таким образом, я думал, что просто составлю новую таблицу с a UserId Столбец (GUID) и отношения FK к aspnet_Users. Однако я затем обнаружил, что не могу легко получить доступ к UserId так как это не выставляется через членство API. (Я знаю, что могу получить доступ к нему через ProviderUserKey, но кажется, что API абстрагирует далеко внутреннее UserID в пользу UserName, и я не хочу заходить слишком далеко против мелкой частицы).
Так, я думал, что должен вместо этого поместить a LoweredUserName столбец в моей таблице, и создает отношения FK к aspnet_Users использование этого. Bzzzt. Неправильно снова, потому что, в то время как существует уникальный индекс в aspnet_Users это включает LoweredUserName, это также включает ApplicationId - таким образом, для создания моих отношений FK, я должен был бы иметь ApplicationId столбец в моей таблице также.
Сначала я думал: прекрасный, я только имею дело с отдельным приложением, таким образом, я просто добавлю такой столбец и дам ему значение по умолчанию. Затем я понял что ApplicationId GUID, таким образом, это была бы боль, чтобы сделать это. Не трудно точно, но пока я не развертываю свой DB, я не могу предсказать то, чем будет GUID.
Я чувствую, что пропускаю что-то или иду о вещах неправильным путем. Что я, как предполагается, делаю?
3 ответа
Я думаю, вы ищете ProfileProvider, который позволяет вам связывать любую произвольную информацию с пользователем.
ДОПОЛНЕНИЕ Если встроенный ProfileProvider не соответствует вашим потребностям, вы можете рассмотреть возможность реализации собственного ProfileProvider, написав класс, производный от System.Web. Profile.ProfileProvider . Это позволит вам написать что-то, что позволяет избежать проблем с сериализацией, о которых вы упомянули в своем комментарии.
ДОПОЛНЕНИЕ Примечание о SqlMembershipProvider. Вы действительно правы, что классы членства действительно привязаны к имени пользователя, даже если схема привязана к UserId. Откровенно говоря, это одна из моих любимых раздражений по поводу классов SqlMembershipProvider. На самом деле это создает проблему в среде с несколькими приложениями, где требуется хранилище для одного пользователя, но независимые списки ролей приложений.
Я бы порекомендовал ввести UserId, поскольку он, как вы упомянули, является первичным ключом таблицы aspnet_Users и используется во всех отношениях внешнего ключа, и это одно значение. Если вы нажмете LowerUsername (и ApplicationId), а имя пользователя изменится, вам необходимо включить каскадное обновление, чтобы изменение отражалось на ваших пользовательских таблицах.
Если вы хотите добавить простые данные, привязанные к вашим пользователям, такие как добавленные свойства профиля, вам следует изучить Персонализация .
Например, если вы хотите сохранить девичью фамилию матери человека как часть информации его профиля, вы можете сделать это с помощью этой функции.
Возможно, это неправильный выбор для сложных данных, но это только начало.
Для этого вы можете реализовать поставщика профиля. Это не очень сложно.В основном вы устанавливаете свои пользовательские настройки следующим образом:
(web.config):
<profile enabled="true" defaultProvider="MyProvider">
<providers>
<add name="MyProvider" connectionStringName="MembershipCnnStr" applicationName="MyApp" type="System.Web.Profile.SqlProfileProvider"/>
</providers>
<properties>
<add name="EmployeeId" type="String" />
<group name="UserSettings">
<add name="IsSandboxMode" type="Boolean" defaultValue="false" />
<add name="Shortcuts" type="System.Collections.Generic.List`1[System.string]" />
</group>
</properties>
</profile>