Членства ASP.NET. Действительно ли это расширяемо?

Question

Членства ASP.NET. Действительно ли это расширяемо?

Я добавляю Свойство "Веб-сайт" как свойство зарегистрированного пользователя.

<profile>
     <providers>
          <clear/>
          <add name="AspNetSqlProfileProvider" connectionStringName="LocalSqlServer" applicationName="membershipSampleApp" type="System.Web.Profile.SqlProfileProvider"/>
     </providers>
     <properties>
         <add name="Website"/>
     </properties>
</profile>

Где то пользовательское свойство хранится в базе данных ASPNETDB, и я могу запросить, это к, например, находит всех пользователей, которые совместно используют то же значение пользовательского свойства?

Если бы я хочу этот вид возможности, я был бы более обеспечен, чтобы увеличить таблицу USERS с моей собственной параллельной таблицей и присоединиться к двум на UserName как ключ?

1

asp.net asp.net-membership

задан abatishchev 25 July 2010 в 16:41

3 ответа

Другие вопросы по тегам:

asp.net asp.net-membership

Похожие вопросы:

score 0 · Answer 1

Реализация профилей по умолчанию жертвует возможностью обнаружения ради простоты использования и гибкости.

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

Отличным и легко реализуемым решением является использование поставщика профилей на основе таблиц.

см. http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx

score 1 · Answer 2

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

Если "Веб-сайт" - это просто свойство пользователя, то, конечно, храните его в профиле. На самом деле это не требует переписывания поставщика членства.

Кроме того, свойство "Website" будет храниться в таблице aspnet_Profiles (как двоичный файл и XML), что может быть затруднительно для запросов. Возможно, имеет смысл иметь пользовательский провайдер профиля, который хранит свойства в обычном формате SQL.

score 1 · Answer 3

Да, вы можете расширить Membership. Вот длинная статья, которая объясняет, как это сделать. В двух словах,

идея расширения API Membership заключается в следующем: Я создам новый класс ExtendedMembershipUser, который унаследует все свойства по умолчанию от MembershipUser, а затем я добавлю свои собственные свойства...

Для хранения значений в базе данных описывается:

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