ASP.NET Членство.Это расширяемое? - PullRequest
1 голос
/ 25 июля 2010

Я добавляю свойство «WebSite» как свойство зарегистрированного пользователя.

<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 в качестве ключа?

Ответы [ 3 ]

1 голос
/ 25 июля 2010

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

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

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

1 голос
/ 25 июля 2010

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

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

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

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

0 голосов
/ 25 июля 2010

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

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

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

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

...