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

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

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

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

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

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

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

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

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

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

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

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

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

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

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