ASP.NET MVC. Расширение HtmlHelper против пользовательского класса
Каковы преимущества расширения HtmlHelper вместо создания пользовательского класса.
fe <% = Html.Table (data)%> vs <% = CustomClass.Table (data)%>
2 ответа
Потому что помощник HTML уже определяет кучу полезных методов, которых у вас не будет в вашем пользовательском классе, и что наиболее важно, у вас есть доступ к HttpContext. Конечно, вы можете сказать, почему бы не передать HttpContext в мой пользовательский класс, но тогда вместо <%= CustomClass.Table(data) %> у тебя будет <%= CustomClass.Table(data, HttpContext) %> который ИМХО страшнее.
Как вы предлагаете, класс HtmlHelper - это просто метод.NET, который возвращает строку (обычно состоящую из разметки HTML). Таким образом, технически это не отличается от написания пользовательского класса тем же.
Однако ключевое преимущество использования HtmlHelper по сравнению с написанием пользовательского класса заключается в том, что он следует традиционному подходу рендеринга элементов управления HTML в представление ASP.NET MVC. Используя / расширяя HtmlHelpers, становится более очевидным, что ваш метод предназначен для вывода разметки HTML для элемента управления. Если бы вы написали собственный класс, чтобы сделать то же самое, было бы менее очевидно, что цель состоит в том, чтобы отобразить элементы управления HTML, и другие разработчики могут не обнаружить его так легко.
Многие считают, что ключевым принципом ASP.NET MVC является одобрение * соглашения над конфигурацией *. Используя HtmlHelpers, вы придерживаетесь этого принципа.