2010-12-08 1 views
23

Я только что прочитал this blog post на Razor Templating в ASP.NET MVC 3.ASP.NET MVC 3 Razor шаблоны VS RenderPartial

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

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

Вот что я не люблю:

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

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

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

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

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

ответ

19

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

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

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

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

U pdate Чтобы лучше проиллюстрировать, как встроенные шаблоны могут быть полезны, я написал сообщение в блоге об использовании их для вызова разделов с кодом по умолчанию: Optional Razor Sections with Default Content.

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

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

Hahah. Свободная мысль - враг. Спасибо @marcind. :) +1 – RPM1984 2010-12-08 05:02:44

3

Распространенное заблуждение о бритве, что он не может быть использован вне контекста ASP.Сетевая среда 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.

 Смежные вопросы

  • Нет связанных вопросов^_^