ASP.NET встроенный профиль пользователя и класс пользователя / таблицы старого стиля

Я ищу рекомендации относительно наилучшей практики использования функции профиля в ASP.NET.

Как вы решаете, что следует хранить во встроенном профиле пользователя, или вам следует создать собственную таблицу базы данных и добавить столбец для нужных полей? Например, у пользователя есть почтовый индекс. Должен ли я сохранить почтовый индекс в собственной таблице или добавить его в профиль xml web.config и получить к нему доступ через механизм ASP.NET профиля пользователя?

Плюсы / минусы, о которых я могу думать прямо сейчас, заключается в том, что, поскольку я не очень хорошо знаю профиль (сейчас это что-то вроде матрицы ), я, вероятно, могу сделать все, что захочу, если пойду за столом (например, SQL для получения всех пользователей в том же почтовом индексе, что и текущий пользователь). Я не знаю, могу ли я сделать то же самое, если я использую профиль ASP.NET.

4.08.2008 23:06:23
5 ОТВЕТОВ
РЕШЕНИЕ

Я только построил 2 приложения, которые использовали профиль провайдера. С тех пор я держался подальше от его использования. Для обоих приложений я использовал его для хранения информации о пользователе, такой как название его компании, адрес и номер телефона.

Это работало нормально, пока наш клиент не захотел найти пользователя по одному из этих полей. Поиск включал циклический просмотр каждого профиля пользователя и сравнение информации с критериями поиска. По мере роста базы пользователей время поиска стало неприемлемым для нашего клиента. Единственным решением было создать таблицу для хранения информации о пользователях. Скорость поиска была увеличена безмерно.

Я бы порекомендовал хранить этот тип информации в отдельной таблице.

11
6.08.2008 02:26:35

Профиль пользователя - это хорошая чистая структура для индивидуальной настройки (AKA. Свойства профиля). (например, iGoogle), проблема в том, что он не предназначен для запросов и не идеален для обмена данными с публичным пользователем (вы все равно сможете это сделать с низкой производительностью).

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

1
29.10.2009 23:42:37

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

0
4.08.2008 23:10:05
> Другая информация, такая как адреса, должна быть сохранена в вашей собственной базе данных с помощью логики вашего собственного приложения. Хорошо, так что это, кажется, путь, может кто-нибудь сказать мне, как лучше связать пользовательские таблицы asp_ с этой новой таблицей? я должен использовать userName в таблице asp_ в качестве ссылки, userID (этот ужасный guid, я даже не знаю, как получить) или что?
csmba 7.08.2008 17:54:24
Вы также можете прокрутить свою собственную пользовательскую таблицу, которая будет содержать ту же информацию, а затем использовать переменные Session или что-то подобное, в этом случае у вас будет полный контроль. На этот раз я переключился на свои собственные пользовательские таблицы и не жалею об этом.
Sean 2.03.2009 01:07:29

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

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

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

Изменить: Кроме того, профили не кэшируются, поэтому каждый доступ к профилю сначала идет в базу данных (затем он кэшируется для этого запроса, но следующий запрос снова получит его из базы данных)

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

0
4.08.2008 23:14:37

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

конечно, это личное предпочтение, но другие подняли некоторые другие важные вопросы.

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

0
5.12.2009 20:19:07