Шаблоны бритвы ASP.NET MVC 3 VS RenderPartial

Я просто прочитал это сообщение в блоге в Шаблоне Razor в ASP.NET MVC 3.

Проще говоря, я просто не понимаю!

То есть я не понимаю, зачем нам этот (справедливый) сложный код для достижения того, что можно сделать IMO проще (и более аккуратно) с помощью @RenderPartial?

Вот что мне не нравится:

  • Шаблон хранится как делегат Func<T,HelperResult>?
  • Этот делегат шаблона сохраняется в представлении Controller ViewData (например, HttpContext.Current.Items)

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

Но я не вижу это как допустимый аргумент. Дополнительные файлы прекрасны, пока организация решения не подвергается риску.

Я предпочитаю использовать @RenderPartial, так как я могу сохранить разметку отдельно от главного представления, и я могу отобразить это как встроенное (время рендеринга), так и jQuery (например, событие AJAX).

Возможно, я что-то пропустил, но может ли кто-нибудь объяснить некоторые причины, по которым мы должны выбрать Razor Templating over RenderPartial для создания повторно используемого контента?

Ответы

Ответ 1

Ну, вы должны спросить автора этой публикации о его мотивации для представления этой техники.

Это, безусловно, иллюстрирует, что возможно в Razor. Следует ли вам использовать это другое дело. Я лично считаю, что существуют альтернативные методы, которые менее сложны (я согласен с вашими соображениями о сохранении Func внутри контекста запроса).

  • Там @RenderPartial, о котором вы уже говорили.
  • Вы также можете использовать синтаксис @helper (либо как локальный помощник, либо глобальный помощник)
  • Вы можете написать html-помощник (и использовать TagBuilder для сборки вывода)
  • Вы можете написать дочернее действие
  • Вы можете написать шаблонный помощник

Теперь, когда я смотрю на приведенный выше список, я думаю, что MVC может предоставить слишком большой выбор:)

Обновить. Чтобы лучше показать, как встраиваемые шаблоны могут быть полезны, я написал сообщение в блоге об использовании их для вызова разделов с кодом по умолчанию: Дополнительные разделы Razor с содержимым по умолчанию.

Вы можете использовать его, чтобы написать что-то вроде этого:

@this.RenderSection("OptionalSection", @<div>Default Content</div>)

Ответ 2

Общим заблуждением о Razor является то, что он не может использоваться вне контекста ASP.Net MVC. Это самый распространенный сценарий, однако мощность бритвенного двигателя выходит за рамки этого.

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

С помощью шаблонов Razor вы можете определить свой шаблон как разметку HTML, где вы можете легко визуализировать и протестировать его.

Вот отличная статья, демонстрирующая эту возможность: http://www.west-wind.com/weblog/posts/2010/Dec/27/Hosting-the-Razor-Engine-for-Templating-in-NonWeb-Applications

Примечание. Я не говорю, что ссылка, на которую вы указали, показывает это, просто пример того, почему вы хотели бы выйти за пределы методов, перечисленных в ответе @marcind.