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

Мне нужны рекомендации относительно лучших практик использования функции профиля в ASP.NET.

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

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

Ответов (5)

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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