ASP MVC HTML Helpers - хорошо или плохо?

Я понимаю причину наличия HTML-помощников в ASP.NET MVC и расширяю его, чтобы предоставить свои собственные, но мне интересно, является ли использование HTML-помощников хорошей идеей.

Я думал, что одним из преимуществ ASP.NET MVC является контроль над HTML. Если вы начнете скрывать его в вспомогательных функциях, генерирующих HTML, вы не теряете видимость? Я думаю, это не такая проблема, когда вы создаете простые элементы управления, такие как кнопка, но я видел использование html-помощников для создания сеток и более сложного вывода HTML.

Теперь я также понимаю, что причина заключается в том, чтобы держать вещи сухими, избегая дублирования. Но разве нет опасности иметь что-то похожее на код? Кроме того, что, если вы работаете в сотрудничестве с дизайнерами? Как правило, дизайнер будет создавать разметку и применять стиль. Если вы начнете вводить свое представление с помощью помощников, которые генерируют разметку, не затрудняет ли это такое сотрудничество?

Ответ 1

"Контроль над HTML" - это маркетинг в области маркетинга, а также то, как они выбирают бренд платформы. Точка ASP.net MVC заключается в том, что она более простая и лучше подходит для webapps, а затем для всей ориентированной на события модели моделей веб-форм и того, что почти все за пределами пространства Microsoft переместились много лет назад. Microsoft не может сказать этого, потому что у них огромные инвестиции в веб-формы, и это ключевая часть их истории предприятия.

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

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

Ответ 2

Отличный комментарий, Мэтт. Вопрос о том, действительно ли в "чистой" реализации MVC, HTML-помощники - хорошая идея. Я думаю, что волшебное слово "чисто". Всякий раз, когда я замедлил думать о "правильном" способе делать вещи, я действительно пытаюсь понять, подходит ли конкретный подход к пуристскому видению. Итак, пурист будет использовать HTML-помощники?

Я около 8/10 пуриста, и я бы не использовал их. Я видел, как этот аргумент превосходил технологии и поднял проблему с MVC в PHP и в рамках Zend. Мне просто нехорошо, и мне кажется, что лучшая мера может придумать.

Ответ 3

Там нет ничего плохого в помощниках. Они используются, чтобы ваши взгляды были чистыми и декларативными. Там высказывание говорит что-то вроде "если есть выражение" если ", на ваш взгляд, вы делаете это неправильно". Они используются во многих известных средах MVC, таких как Ruby On Rails и Cake PHP. Отметьте этот пост. "Пурист" или нет, помощники - это хорошо, и их нельзя путать с плохой практикой или негерметичными абстракциями.

Ответ 4

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

Вы можете сразу переместить HTML, javascript и CSS в приложение на другой платформе. Вам не нужно преобразовывать все уродливые HTMLHiders.. извините, HTMLHelpers.. до фактического HTML.

Несмотря на то, что я очень уважаю платформу .NET, которая сокращает время разработки и упрощает мою работу, я твердо убежден в том, что мнения должны быть непатентованными.

В любом случае вы можете получить почти все преимущества от структуры в модели и контроллере. Инъекционные зависимости от структуры в вашем слое презентации вообще не стоят компромисса, IMO.