С# MVC: производительность и преимущества MVC Html Помощники против прямого HTML в представлениях
Я хотел бы знать, какое влияние оказывает влияние помощники Html на представления С# ASP.NET MVC, особенно при настройке параметров атрибута, и какие преимущества у них есть в целом (зачем их использовать?)
С помощью Html Helpers:
<%= Html.TextBox("firstName", Model.FirstName,
new { @disabled = "disabled", @class = "myCssClass" }) %>
Direct Html:
<input type="text" class="myCssClass" name="firstName"
disabled="disabled" text="<%= Model.FirstName %>"/>
У меня довольно много страниц, содержащих от 5 до 15 таких входов. Кроме того, Html Helpers позволяет вам отображать форму (думаю, Html.BeginForm()) и т.д., Так что вы, возможно, получите 20 или более вызовов Html Helper. Я думаю, что некоторые из них тоже используют отражение. когда вы устанавливаете такие атрибуты, как отключенный выше.
Разве это не влияет на производительность? Почему, на мой взгляд, лучше использовать этих помощников? Пожалуйста, кто-нибудь даст мне вескую причину:) Я бы хотел использовать их, но я действительно опасаюсь влияния производительности, которое у них есть.
Есть ли реальные преимущества для использования Html-помощников?
Ответы
Ответ 1
Накладные расходы на размышления - это то, о чем люди действительно любят беспокоиться. Однако, помимо синтетических тестов, это становится довольно скучной темой!
В контексте реального производственного приложения (где вы делаете операции CRUD с базами данных или, например, используете веб-сервис), накладные расходы на использование html-помощников будут незначительными по сравнению с накладными расходами на выполнение такого типа контекста переключатель.
На самом деле не о чем беспокоиться, особенно учитывая преимущества, предоставляемые html-помощниками, такие как автоматическое восстановление значений форм из ViewData/Model и поддержка проверки.
Нижняя строка: используйте html-помощники, когда это возможно. Вы всегда можете использовать прямой html, если у вас есть редкое ограничение, которое вам нужно обойти.
Ответ 2
Есть ли реальные преимущества для использования Html-помощников?
Самое большое преимущество, которое я вижу в использовании HtmlHelpers, - это обеспечить уровень абстракции для вашей разметки. Если в будущем вы захотите изменить структуру своей разметки, вам нужно только изменить результат, созданный помощниками, в отличие от просмотра всех ваших представлений и внесения изменений вручную.
Это также способствует согласованности между командами разработчиков. Эти разработчики не обязаны знать точные сведения о структуре разметки и классах css, на которых основан ваш интерфейс.
В качестве примера я в настоящее время разрабатываю новую структуру пользовательского интерфейса для компании, в которой я работаю, на основе Bootstrap. Я создал набор HtmlHelpers, которые генерируют соответствующие классы разметки и css для различных компонентов Bootstrap. Все это делается в Fluent API, который хорош для разработчиков, без каких-либо глубоких знаний, необходимых для Bootstrap, плюс с дополнительным преимуществом наличия Intellisense.
Telerik Основа Kendo UI основана на той же концепции. Взгляните на некоторые из их образцов кода.
Что касается отражения и производительности, я действительно не стал бы волноваться, учитывая количество вызовов, которые могут быть задействованы в нескольких методах HtmlHelper. См. Этот пост по причинам.
Ответ 3
Я сделал это в обоих направлениях, и производительность, похоже, примерно такая же. Фил Хаак говорит, что вы можете сделать это в любом случае - что помощники - это просто помощники, и если вы предпочитаете, вы можете написать Plain Old HTML.
Я не уверен, что помощники более безопасны... так или иначе вы завершаетесь тем же HTML-кодом на веб-странице... но по-видимому, intellisense работает лучше в помощниках, что хороший.
С помощью помощников проще сделать выпадающие меню, так как вам не нужно разворачивать цикл для списка выбора. Скрытые поля и текстовые поля (и ссылки) выглядят лучше, чем мои глаза, в обычном HTML, особенно если они содержат несколько атрибутов, поскольку вы можете избежать синтаксиса инициализации этого объекта.
Обычный HTML выглядит хорошо с jQuery (см. здесь пример). И простой HTML просто читать легче.
Я считаю, что вспомогательные методы полезны, когда вы хотите вложить большую структуру в html. Через несколько месяцев вы найдете сайты, богатые этими методами, которые будут поддерживать все виды функциональности. Представьте, что вы можете ввести граф на свою страницу с помощью одной строки кода.
Ответ 4
В HtmlHelpers нет никакого отражения. Последний параметр не является объектом, его словарем, поэтому поиск значений осуществляется через хеш-таблицу, а не отражение. HtmlHelper хорош в том, что его методы безопасны и безопасны... ввод закодирован там, где это необходимо, проверки безопасности формируются там, где это необходимо, и т.д. HtmlHelpers намного больше, чем просто рендеринг html.
Ответ 5
Ваше действие контроллера (вызванное GET) приводит к тому, что многие случаи должны быть кэшированы для достижения хорошей производительности. Поэтому вы не должны беспокоиться о времени выполнения View. Для меня трудно представить ситуацию, когда ваше время исполнения HtmlHelper может стать узким местом производительности.
