ASP.NET MVC Razor view engine

Question

После прочтения записи в блоге Скотта Гатри о новом движке Razor для ASP.NET MVC и прочтения этого вопроса со сравнением доступных механизмов просмотра.

Кажется, что Razor решает большинство проблем с механизмом представления по умолчанию. Какие функциональные различия сделали бы его привлекательным выбором для вас, как для разработчика? Какие функции отсутствуют, которые не позволят вам использовать его?

Answer 1

Unit Testable: новая реализация движка представлений будет поддерживать возможность просмотра модульных тестов (без использования контроллера или веб-сервера и может быть размещена в любом проекте модульного тестирования - не требуется специальный домен приложения).

Наконец-то !!!Не могу поверить, что Microsoft потребовалось почти 8 лет, чтобы наконец создать движок представления, который поддерживает это.

Answer 2

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

• писать расширения html, используя тот же язык разметки, а не C # (макросы) - я вижу, что Razor также поддерживает это, я надеюсь, что он поддерживает переопределение методов / параметров;
• пользовательские теги (напишите _Tag.spark для использования);
• автоматически сгенерированные переменные, такие как varIsFirst, varIndex и т. Д .;
• формы специальных выражений (? {} Для условных атрибутов, $! {} Для пропуска ошибок и т. Д.);
• хорошая поддержка основных / частичных макетов, включая возможность частичного указания того, что часть разметки должна отображаться в мастере только один раз (например, скрипт включает в себя);
• у вас все еще может быть разметка WebForms - отлично подходит для совместимости и постепенного обновления;
• поддержка использования кавычек "" и "внутри друг друга (очень полезно).

Мне больше нравится синтаксис Spark для циклов / ifs - смешивание HTML <> и C #{} фигурные скобки выглядят не слишком красиво, но это сугубо личное мнение.

В Razor также есть многообещающие функции, например встроенные шаблоны.Учитывая, что создатель Spark был нанят Microsoft, я думаю, у Razor есть надежда быть хорошо написанным, очень полезным и хорошо поддерживаемым движком представления.Конечно, я не буду переписывать сотни моих представлений Spark с помощью Razor (хотя я переписал десятки моих представлений WebForms с помощью Spark).Но я, безусловно, серьезно посмотрю на Razor - я узнал об этом только из ваших вопросов, спасибо - и то, что я вижу сейчас, выглядит многообещающе.Конечно, он не конкурирует с WebForms (любой механизм просмотра лучше, чем WebForms), но выглядит хорошим выбором для нового проекта ASP.NET MVC, если вы еще не вложили слишком много в другой механизм просмотра.

Answer 3

Для меня есть три веские причины:

1. Компиляция - Вид бритвы может быть скомпилирован в DLL. Наконец мы получаем правильное повторное использование в веб-проектах .NET. У меня может быть бизнес-объект, который знает, как отображать себя, не используя этот код в виде файлов .ascx в какой-то части веб-проекта.

2. Тестируемость - поскольку он скомпилирован в класс, я могу написать модульный тест и выбросить в него проверенные экземпляры объектов, чтобы проверить, верен ли HTML.

3. IntelliSense и Краткий синтаксис - это приятные, но не самые важные части.

Answer 4

Очевидно, что я еще не оценил его на практике, но тот факт, что он короче, чем механизм ASPX, является наиболее убедительным признаком переключения.Я только надеюсь, что он также автоматически форматирует более красиво.Тот факт, что он будет поддерживаться с Intellisense и поставляется с MVC, делает его естественным выбором для запуска новых проектов.Я собираюсь дать ему шанс на небольшой проект, прежде чем я сделаю переход.Просто прочитав статью, я не увидел ничего такого, что я бы не смог с этим сделать, что я сейчас делаю с движком ASPX.уже более года пользуюсь Razor и никогда не вернусь к движку ASPX.Синтаксис кажется очень естественным и выразительным.

Answer 5

Бритва использовать скобки, то есть для foreach материала.Spark использует здесь XML-теги.

Итак, Spark полностью поддерживает синтаксический анализ и анализ файла представления для каждого процессора XML.

Mabye, что не так уж важно, но демонстрирует последовательность и расширяемость.

Answer 6

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