Механизм представления ASP.NET MVC Razor
После чтения записи в блоге Scott Guthrie о новом механизме представления Razor для ASP.NET MVC и чтение этого вопроса, сравнивающего доступные механизмы представления.
Бритва, кажется, решает большинство проблем с механизмом представления по умолчанию. Какие значения в функции имели бы его востребованным выбором для Вас как разработчик? В чем функции испытывают недостаток, который помешал бы Вам использовать его?
6 ответов
Есть еще много чего интересного в движке, кроме языка разметки. Несколько возможностей Spark, которых мне будет не хватать:
- писать расширения html, используя тот же язык разметки, а не C# (макросы) - я вижу, что Razor также поддерживает это, надеюсь, он поддерживает переопределение методов/параметров;
- пользовательские теги (напишите _Tag.spark, чтобы использовать
); - автогенерируемые переменные, такие как varIsFirst, varIndex и т.д.;
- специальные формы выражений (?{} для условных атрибутов, $! {} для пропуска ошибок и т.д.);
- хорошая поддержка макетов master/partial, включая возможность указать в partial, что часть разметки должна отображаться только один раз в master (например, script includes);
- вы все еще можете иметь разметку WebForms - отлично подходит для совместимости и постепенного обновления;
- поддержка использования кавычек "" и '' внутри друг друга (очень полезно).
Мне больше нравится синтаксис Spark для циклов/ifs - смешение скобок HTML <> и C# {} выглядит не слишком красиво - но это чисто личное мнение.
В Razor тоже есть многообещающие возможности, например, встроенные шаблоны. Учитывая, что создатель Spark был нанят Microsoft, я думаю, есть надежда, что Razor будет хорошо написанным, очень полезным и хорошо поддерживаемым движком представления. Конечно, я не стану переписывать сотни своих представлений Spark на Razor (хотя я переписал десятки своих представлений WebForms на Spark). Но я обязательно серьезно посмотрю на Razor - я узнал об этом только из ваших вопросов, спасибо - и то, что я вижу сейчас, выглядит многообещающе. Конечно, он не конкурирует с WebForms (любой движок представления лучше WebForms), но он выглядит хорошим выбором для нового проекта ASP.NET MVC, если вы еще не вложили слишком много средств в другой движок представления.
Помимо более чистого вида, гибкость секций макета выглядит очень хорошо, а декларативные HTML-помощники выглядят очень полезными. Пока что я не вижу никаких недостатков в его использовании, но, конечно, нужно будет попробовать его на практике.
Unit Testable: новый механизм просмотра реализация поддержит возможность просмотра юнит-тестов (без требуется контроллер или веб-сервер, и может быть размещен в любом модульном тесте проект - специального приложения-домена нет требуется).
Наконец-то !!! Не могу поверить, что Microsoft потребовалось почти 8 лет, чтобы наконец создать движок просмотра, который поддерживает это.
Разумеется, я еще не оценивал его на практике, но тот факт, что он работает быстрее, чем движок ASPX, является наиболее убедительной особенностью, побуждающей к переходу. Я только надеюсь, что он также лучше автоформатирует. Тот факт, что он будет поддерживаться intellisense и поставляться с MVC, делает его естественным выбором для начала новых проектов. Я собираюсь попробовать его на небольшом проекте, прежде чем переходить на него. Просто прочитав статью, я не увидел ничего такого, что я не смог бы сделать с его помощью, что я сейчас делаю с помощью движка ASPX.
Обновление: Я использую Razor уже более года и никогда не вернусь к движку ASPX. Синтаксис кажется очень естественным и выразительным.
Razor использует Brackets, то есть для foreach вещей.
Spark использует здесь теги XML.
Таким образом, Spark полностью поддерживает разбор и анализ файла представления в XML-процессоре.
Может быть, это не очень важно, но показывает последовательность и расширяемость.
Для меня есть три веские причины:
Компиляция - представления Razor могут быть скомпилированы в DLL. Наконец-то мы получили правильную возможность повторного использования в веб-проектах .NET. У меня может быть бизнес-объект, который знает, как отображать себя без того, чтобы этот код перемещался в виде файлов .ascx в какой-либо части веб-проекта.
Тестируемость - поскольку он скомпилирован в класс, я могу написать модульный тест и бросить в него имитируемые экземпляры объектов, чтобы проверить правильность HTML.
IntelliSense и Краткий синтаксис - хорошие, но не самые важные части.