Переход от веб-сайта ASP.NET к веб-проекту ASP.NET, профилям и тому, что действительно будет лучшим способом для этого - PullRequest
0 голосов
/ 25 октября 2011

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

Это предлагалось во многих местах в Интернете.Но, обнаружив это, я отправился на поиски дополнительной информации по этому вопросу, и одна публикация, которую я нашел, была посвящена stackoverflow, она показала в основном концепцию, которую я видел опубликованную где-то в другом месте, но один комментарий к ней привлек мое внимание, публикация: Как назначить значения профиля? и комментарий: «Этот код, вероятно, недостаточно быстр для сайта с 1 000 000 просмотров страниц в день. Когда я писал это, я работал над другим проектом».

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

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

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

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

...