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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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