ASP.NET, встроенный в профиль пользователя, по сравнению с классом / таблицами пользователя в старом стиле
Мне нужны рекомендации относительно лучших практик использования функции профиля в ASP.NET.
Как вы решаете, что следует хранить во встроенном профиле пользователя, или вам следует создать свою собственную таблицу базы данных и добавить столбец для желаемых полей? Например, у пользователя есть почтовый индекс. Следует ли мне сохранить почтовый индекс в своей таблице или добавить его в xml-профиль web.config и получить к нему доступ через механизм профиля пользователя ASP.NET?
Плюсы / минусы, о которых я могу думать прямо сейчас, заключаются в том, что, поскольку я не очень хорошо знаю профиль (сейчас это немного похоже на Матрица), я, вероятно, могу делать все, что захочу, если пойду по маршруту стола (например, SQL, чтобы все пользователи имели тот же почтовый индекс, что и текущий пользователь). Я не знаю, смогу ли я сделать то же самое, если буду использовать профиль ASP.NET.
Ответы 5
По моему опыту, лучше всего сводить информацию в профиле к минимуму, помещать туда только самое необходимое, что напрямую необходимо для аутентификации. Другая информация, такая как адреса, должна сохраняться в вашей собственной базе данных с помощью логики вашего собственного приложения, этот подход более расширяем и удобен в обслуживании.
Вы также можете свернуть свою собственную таблицу пользователей, которая будет содержать ту же информацию, а затем использовать переменные сеанса или что-то подобное, в этом случае у вас будет полный контроль. На этот раз я перешел на свои пользовательские таблицы и не жалею об этом.
Я думаю, это зависит от того, сколько полей вам нужно. Насколько мне известно, профили - это, по сути, длинная строка, которая разделяется с заданными размерами полей, что означает, что они не очень хорошо масштабируются, если у вас много полей и пользователей.
С другой стороны, они встроены, так что это простой и стандартизованный способ, а это означает, что нет большой кривой обучения, и вы также можете использовать его в будущих приложениях без необходимости настраивать его для новой структуры таблицы.
Сворачивание собственной вещи позволяет вам поместить ее в должным образом нормализованную базу данных, что резко повышает производительность, но вам придется писать практически весь код управления профилями самостоятельно.
Обновлено: Кроме того, профили не кэшируются, поэтому каждый доступ к профилю сначала идет в базу данных (затем он кешируется для этого запроса, но следующий запрос снова получит его из базы данных)
Если вы думаете о написании своей собственной вещи, возможно, поставщик настраиваемого профиля дает вам лучшее из обоих миров - бесшовную интеграцию, но при этом настраиваемые вещи, которые вы хотите делать.
Я создал только 2 приложения, которые использовали поставщика профилей. С тех пор я воздерживался от его использования. В обоих приложениях я использовал его для хранения информации о пользователе, такой как название компании, адрес и номер телефона.
Это работало нормально, пока наш клиент не захотел найти пользователя по одному из этих полей. Поиск включал в себя цикл по профилю пользователя каждый и сравнение информации с критериями поиска. По мере роста пользовательской базы время поиска стало неприемлемым для нашего клиента. Единственным решением было создать таблицу для хранения информации о пользователях. Скорость поиска была значительно увеличена.
Я бы рекомендовал хранить такую информацию в отдельной таблице.
Профиль пользователя - это хорошая чистая структура для индивидуальной настройки (AKA. Profile Properties). (например, iGoogle) проблема в том, что он не предназначен для запросов и не идеален для обмена данными с общедоступным пользователем. (вы все равно сможете это сделать с низкой производительностью)
Итак, если вы хотите улучшить индивидуальный пользовательский интерфейс, профиль пользователя будет хорошим вариантом. в противном случае использование вашего собственного класса и таблицы было бы гораздо лучшим решением.
Я думаю, что лучше использовать его для дополнительных данных, которые не критичны для пользователя, которые обычно важны только тогда, когда этот пользователь все равно входит в систему. Подумайте о данных, которые не сломали бы ничего важного, если бы все было стерто.
конечно, это личное предпочтение, но другие подняли и другие важные вопросы.
Также очень полезно, учитывая, что его можно использовать для неаутентифицированного пользователя, профиль которого поддерживается анонимным файлом cookie.
> Другая информация, такая как адреса, должна быть сохранена в вашей собственной базе данных с помощью логики вашего собственного приложения. Хорошо, так что, похоже, это правильный путь, может ли кто-нибудь сказать мне, как лучше всего связать пользовательские таблицы asp_ с этой новой таблицей? должен ли я использовать имя пользователя в таблице asp_ в качестве ссылки, идентификатор пользователя (этот уродливый гид, который я даже не знаю, как получить) или что?