Механизм просмотра ASP.NET MVC Razor

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

• Testability - поскольку он скомпилирован в класс, я могу написать unit test и выкинуть в него объекты с надписями, чтобы увидеть, правильно ли HTML.

• IntelliSense и Тесный синтаксис являются приятными, но не самыми важными частями.

Ответ 4

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

Обновление: Я использую Razor уже более года и никогда не вернусь к движку ASPX. Синтаксис кажется очень естественным и выразительным.

Ответ 5

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

Ответ 6

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

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

Маби, это не большая вещь, но показывает последовательность и расширяемость.