не больше и не меньше, чем любой другой элемент управления, добавленный на страницу.Помните, что КАЖДЫЙ серверный элемент управления, который вы добавляете на страницу, имеет тот же жизненный цикл и имеет свой собственный.
Конечно, это предполагает, что вы (или какой-либо другой разработчик) не делаете что-то АКТИВНОснизить производительность (т. е. подсчитать до миллиарда за каждую загрузку страницы не поможет производительность).
Редактировать
Хорошо, вот в чем дело.
Во-первых, вы просите ответить «да» или «нет» на вопрос, ответ которого «это зависит».И ответ «это зависит», потому что я не знаю, как пользовательский контроль подвергается пыткам в связанном коде.
Во-вторых, я собираюсь добавить больше текста здесь.По сути, я собираюсь повторить то, что я сказал в четырех предложениях выше, примерно в 1000 слов.Итак ....
Если вы берете совершенно новый пользовательский контроль.Не добавляйте код к нему в CodeBehind.Не оставляйте серверные элементы управления на стороне ASPX.
Тогда не будет никакой разницы в том, как это повлияет на производительность, чем добавление Asp: Button или ASP: Label в конструктор повлияет на производительность.
ЧТОБЫ ОЧИСТИТЬ: Пока вы не добавите материал в пользовательский элемент управления, он не будет более или менее влиять на производительность веб-сайта, чем любой серверный элемент управления.
Будет ли "влияние" на производительность?Технически, да, но эффективно, нет.
И это очень важное различие.Помните, что каждый элемент управления на стороне сервера оказывает минимальное влияние на производительность.Это созданные объекты, а созданные объекты потребляют память и ресурсы.Конечно, это влияние незначительно, и я бы посчитал это незначительное влияние «деградацией», когда вы добавляете сотни элементов управления (сервер или пользователь) на страницу.
ИСПОЛЬЗОВАНИЕ пользовательских элементов управления не там, где вам нужно беспокоиться.
Ваша задача должна заключаться в РЕАЛИЗАЦИИ пользовательского элемента управления.
Когда программист входит в этот CodeBehind и начинает делать глупости, чтобы съесть память и циклы процессора, все начинает ухудшаться.Альтернативно, то, как программист реализует пользовательский элемент управления, может улучшить производительность веб-приложения (как сказал Дэвид здесь ).
Редактировать 2
Вопрос "в общем, хорошо ли использовать пользовательский контроль вместо того, чтобы не выполнять ту же работу", не является вопросом, который вы задаетеспрашиваю выше.Если задача, которую вы выполняете, снижает производительность, не имеет значения, находится ваша задача в пользовательском элементе управления или нет.Кроме того, если это хорошая идея, зависит от проекта, команды, масштабов и, возможно, даже дизайн парадигм.
- Ответ на вопрос «в общем, есть ли снижение производительности при использовании пользовательского элемента управления» - «фактически нет».
- Ответ на вопрос «в общем, хорошая идея» - «это зависит».
- Ответ на «в общем, будет ли задача лучше в UserControl или нет», опять же, «это зависит».
Без подробностей о вашей конкретной ситуации (кодовая база, дизайн, команда разработчиков, команда обслуживания и т. Д.) Лучшего ответа не может быть.
Я создал приложения, в которых использование пользовательского элемента управления было излишним и привело бы к ненужному вздутию приложения.Я создавал приложения, в которых использование пользовательского элемента управления не было достаточно точным и активно использовалось для серверной части [мы динамически создавали элементы управления, поэтому мы использовали пользовательские и составные серверные элементы управления, а не пользовательские элементы управления (весь код по сравнению с кодом + конструктор)].И я создал приложения, где пользовательские элементы управления были идеальным решением.
Но все эти решения были приняты из-за дизайна.