Комментарии 16
А почему бы сразу не перейти на использование ASP.NET MVC, нежели допиливать веб-формы до преимуществ MVC? Тем более для плавного перехода вы могли бы скомбинировать Forms и MVC.
Это советы могут помоч тем, у кого уже есть готовый рабочий проект на WebForms и требуется за 2-3 дня его оптимизировать, а не тратить еще существенное количество времени на то, чтоб перевести на MVC
Попробую высказать «за»:
— если уметь правильно готовить webforms, то можно достичь хорошей производительности;
— часто разработчики переключаются с winforms на webforms и наоборот, что позволяет экономить время на освоение технологии (конечно, при этом первый пункт будет хромать без хорошего техлида);
— большая библиотека контролов;
— положительное мнение о технологии со стороны крупных заказчиков (как известно, мир enterprise внедряет новинки с некоторым запозданием);
— проблемы с производительностью Razor.
— если уметь правильно готовить webforms, то можно достичь хорошей производительности;
— часто разработчики переключаются с winforms на webforms и наоборот, что позволяет экономить время на освоение технологии (конечно, при этом первый пункт будет хромать без хорошего техлида);
— большая библиотека контролов;
— положительное мнение о технологии со стороны крупных заказчиков (как известно, мир enterprise внедряет новинки с некоторым запозданием);
— проблемы с производительностью Razor.
Потому что mvc это не следующая, более крутая версия asp.net worms. Это взаимодополняющие инструменты под разные задачи. Хотя и микроскопом можно гвозди забивать…
Отключите ViewState, не используйте стандартные контролы, не используйте ScriptManager и UpdatePanel — это конечно хорошо. А что остается в итоге? зачем тогда вообще WebForms здесь?
Если у вас старое приложение, то можно подключить MVC и делать новые страницы на нем.
Если у вас старое приложение, то можно подключить MVC и делать новые страницы на нем.
Действительно, статья скорее по теме «Как не использовать webforms». Все фишки, которые мы отключаем призваны упростить работу девелопера в ущерб скорости и объема. Пишете Highload — не используется вебформы.
Статья для тех, у кого есть решение на Web Forms и перевод на MVC пока не планируется либо намечен на будущее. Думаю в разных компаниях могут быть абсолютно разные сложности с быстрым переходом на MVC. Думаю для Web Forms разработчиков самое оно, чтобы лишний раз увидеть как другие разработчики добились хорошего результата, не выкидывая половину что писали и не начиная все заново.
Не находите, что 4 уровня if-ов как-бы слишком? Сложно было обойтись 2-мя?
Насколько я помню, в последнем фреймворке можно пользоваться Bundle, который сожмет вам все необходимые ресурсы в релизе. А что касается собственного модуля — чем он лучше стандартного динамического сжатия IIS? Тем, что можно использовать на shared хостингах?
Видим, что для вывода простого текста внутри UpdatePanel потребовалось 2 кб html и еще почти 100 кб скриптов.
И насколько это много? На серьезных проектах обычно полно разметки и скриптов целая пачка. Решается клиентским кешированим и сжатием скриптов.
ViewState. Однако в большинстве случаев без него можно обойтись.
Это стандартный механизм для работы с состоянием клиентского вью. Лучше там нет. Какой выигрыш дает отказ от него? Эта игра действительно стоит свеч?
при разработке контролов для ASP.NET не особо задумывались о чистоте и оптимальности верстки, количестве запросов и скорости работы этих самых контролов.
Еще как задумывались. Да — генеренная верстка там не оптимальна — но механизм позволяет абстрагироваться от от html и рассматривать его в ряде случаев как некий веб ассемблер. Стандартные контролы удобны в использовании если уметь их готовить. Проблема только в производительности — но она решается отдельными механизмами. Уходить от них опасно — придется смешивать разные стили разработки, подружить разные инструменты — дополнительные риски.
По минимизации javascript и сжатию html снимаю шляпу. Это правильно — и это стандарт разработки под asp.net.
Хотелось бы увидеть результаты тестирования производительности продукта. Без цифр невозможно оценить стоит ли использовать значительную часть из приведенных вами механизмов.
И насколько это много? На серьезных проектах обычно полно разметки и скриптов целая пачка. Решается клиентским кешированим и сжатием скриптов.
ViewState. Однако в большинстве случаев без него можно обойтись.
Это стандартный механизм для работы с состоянием клиентского вью. Лучше там нет. Какой выигрыш дает отказ от него? Эта игра действительно стоит свеч?
при разработке контролов для ASP.NET не особо задумывались о чистоте и оптимальности верстки, количестве запросов и скорости работы этих самых контролов.
Еще как задумывались. Да — генеренная верстка там не оптимальна — но механизм позволяет абстрагироваться от от html и рассматривать его в ряде случаев как некий веб ассемблер. Стандартные контролы удобны в использовании если уметь их готовить. Проблема только в производительности — но она решается отдельными механизмами. Уходить от них опасно — придется смешивать разные стили разработки, подружить разные инструменты — дополнительные риски.
По минимизации javascript и сжатию html снимаю шляпу. Это правильно — и это стандарт разработки под asp.net.
Хотелось бы увидеть результаты тестирования производительности продукта. Без цифр невозможно оценить стоит ли использовать значительную часть из приведенных вами механизмов.
При любом событии внутри UpdatePanel происходит PostBack и выполняются все события страницы, в которых могут происходить трудные вычисления или запросы к базе данных.
Это решается серверным кешированием в сессию по моему. Вроде так и задумывался механизм — нет?
Это решается серверным кешированием в сессию по моему. Вроде так и задумывался механизм — нет?
Кеширование в сессию вызывает лишнюю сериализацию и при большом количестве пользователей сессия будет очень разрастаться. Да еще придется делать механизм поддержки актуальной информации в сессии. И вообще, кеширование — это последнее средство по оптимизации, лучше разработать правильную архитектуру, чем пытаться дыры в производительности затыкать кешем.
Это стандартный механизм для работы с состоянием клиентского вью. Лучше там нет. Какой выигрыш дает отказ от него?
Да, не спорю, вьюстейт иногда очень полезен, но… если им правильно пользоваться. Проблемы начинаются, например когда на странице выводится только статический текст, да пара текстбоксов, а вьюстейт может весить десятки килобайт.
Не призываю полностью от него избавляться, просто отключать где не нужно.
Да, не спорю, вьюстейт иногда очень полезен, но… если им правильно пользоваться. Проблемы начинаются, например когда на странице выводится только статический текст, да пара текстбоксов, а вьюстейт может весить десятки килобайт.
Не призываю полностью от него избавляться, просто отключать где не нужно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Несколько способов ускорить приложение на ASP.NET WebForms