C # MVC: производительность и преимущества HTML-помощников MVC по сравнению с Direct HTML в представлениях

Question

Хотелось бы узнать, какое влияние на производительность Html-помощники оказывают на представления C # ASP.NET MVC, особенно при настройке параметров атрибутов, и какие преимущества они имеют в целом (зачем их использовать?)

С помощью Html Helpers:

<%= Html.TextBox("firstName", Model.FirstName, 
    new { @disabled = "disabled", @class = "myCssClass" }) %>

Прямой HTML:

<input type="text" class="myCssClass" name="firstName" 
     disabled="disabled" text="<%= Model.FirstName %>"/>

У меня довольно много страниц, которые содержат от 5 до 15 таких входных данных. Вдобавок к этому Html Helpers позволяют вам отображать форму (например, Html.BeginForm ()) и т. Д., Так что вы потенциально можете получить 20 или даже больше вызовов Html Helper. Я думаю, что некоторые из них тоже используют рефлексию, например когда вы устанавливаете атрибуты, такие как отключенный выше.

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

Есть ли какие-либо реальные преимущества использования Html-помощников?

Answer 1

Затраты на размышления - это то, о чем людям действительно нравится беспокоиться. Однако за пределами синтетических тестов это становится довольно скучной темой!

В контексте реального производственного приложения (где вы выполняете операции CRUD с базами данных или, например, используете веб-сервис), издержки на использование html-помощников будут незначительными по сравнению с издержками на выполнение такого рода контекста. переключатель.

Не о чем беспокоиться, особенно если учесть преимущества, предоставляемые html-помощниками, такие как автоматическое восстановление значений форм из ViewData / Model и поддержка проверки.

Итог: используйте HTML-помощники, когда это возможно. Вы всегда можете использовать прямой HTML, если вы столкнетесь с редким ограничением, которое нужно обойти.

Answer 2

Есть ли реальные преимущества использования Html-помощников?

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

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

Например, в настоящее время я разрабатываю новую инфраструктуру пользовательского интерфейса для компании, в которой я работаю, на основе Bootstrap. Я создал набор HtmlHelpers, которые генерируют соответствующие классы разметки и CSS для различных компонентов Bootstrap. Все это делается с помощью Fluent API, который удобен для разработчиков, без каких-либо глубоких знаний, необходимых для Bootstrap, плюс дополнительное преимущество доступности Intellisense.

Платформа Telerik Kendo UI основана на той же концепции. Взгляните на некоторые из их примеров кода.

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

Answer 3

Я сделал это обоими способами, и производительность кажется примерно одинаковой. Фил Хаак говорит, что вы можете сделать это любым способом - что помощники - это просто помощники, и если вы предпочитаете, вы можете написать простой старый HTML.

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

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

Обычный HTML хорошо сочетается с jQuery ( см. Здесь пример ). А простой HTML легче читать.

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

Answer 4

Ваши действия контроллера (вызванные GET) во многих случаях должны кэшироваться для достижения хорошей производительности. Поэтому вам не нужно беспокоиться о времени выполнения вашего View. Мне трудно представить ситуацию, когда время выполнения вашего HtmlHelper может стать узким местом производительности.

Answer 5

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