Искрить или не искры?

В последнее время на огромном обучении с ASP.MVC 2, а в последнее время обнаружены разные механизмы рендеринга... Искра особенно привлекла мое внимание, хотя бы пару вещей.

У меня есть обширные знания с ASP.NET, так что стоит наращивать, в дополнение к ASP.NET MVC
Стоит ли вообще? Это действительно имеет значение? Кажется, что предпочтение отдается на самом деле и не столько производительности, либо даже существенному сокращению времени разработки.
Это по-прежнему кажется незрелой, не очень хорошая поддержка intellisense, поддержка подсветки синтаксиса, не многие опции инструментария. Он имеет предварительную поддержку только для MVC 2...

Каковы ваши мысли? Я склоняюсь к нему, вероятно, не стоит того...

Ответ 1

Отвечая на вопрос о трех частях в порядке...

Вероятно, это хорошая идея, чтобы изучать новые вещи по одному. Тем более, что почти все примеры и руководства MVC будут в синтаксисе WebForms. Тем не менее, лучше всего учиться в экспериментальном решении, а не в вашем "реальном" проекте, поэтому после того, как вы почувствуете, что у вас есть концепции MVC, неплохо создать новую песочницу и попробовать несколько страниц MVC + Spark.
Производительность с точки зрения давления памяти или использования процессора, вероятно, не является самым важным фактором для всех, кроме крупнейших веб-сайтов... Влияние на разработчиков и время разработки дизайнера/творчества может быть небольшим поначалу, но он кумулятивный и нелинейный. Немного упрощения фронта избавит вас от лобовых болей в будущем, а "простой, простой синтаксис" является краеугольным камнем предпосылки двигателя просмотра Spark.
Это очень верно. Польский и изысканный опыт - самая дорогая часть инструментов и современных IDE. Я думаю, что большинство веб-стеков OSS начинаются с отличного редактора (кашель TextMate cough) и работают оттуда. С помощью Spark вы можете получить csharp-язык intellisense, но это, безусловно, знак низкой воды для поддержки инструмента.

Это анекдотично, но одним из способов измерения является то, как многие люди жалуются на использование Spark и обратно. Я не уверен в многих - хотя задержка из ворот в получении поддержки MVC 2 заставила некоторых людей задаться вопросом, я уверен.

Ответ 2

Зависит от того, что вы хотите сделать с ASP.NET MVC. Мы находимся в середине создания с ней большого корпоративного приложения, и я немного хочу, чтобы мы использовали Spark. Но это было только после того, как наш 200-й взгляд был завершен, и я чувствовал себя достаточно комфортно с каркасом, чтобы рассмотреть возможность привязки к чему-то еще.

Я бы порекомендовал сначала создать несколько небольших приложений с помощью обычного механизма просмотра, и если вы обнаружите, что боретесь с супом "tag soup", вернитесь и подумайте о том, почему. Во многих случаях это просто означает, что вы должны были сделать лучшую ViewModel и сопоставленные данные, создать хелпер html или использовать неполный файл, а не заполнять свой вид супом-тегом.

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

Ответ 3

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

Искра значительно ближе к голой HTML, чем ASP.net

В целом у программиста без программирования HTML будет больше шансов понять Spark и работать с ним, чем ASP.net

Если это проблема, вы используете Spark, в противном случае используйте то, что вы хотите. Проверьте nhaml для чего-то другого

Ответ 4

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

Конечно, есть некоторые хитроумные вещи, такие как intellisense и включаются для предварительной компиляции. Но, по моему мнению, преимущества более значительны. "Читаемость" взглядов намного лучше искры. Существует более элегантное разделение на частичные (опять же мое личное мнение). Я также нашел искровой путь локализации сайта более естественным (MyView.spark, MyView.de.spark, MyView.de-DE.spark с автоматическим резервным копированием и тем же самым для мастер-макетов). Множество небольших удобств - лучше всего я люблю ${} и! {}, Чтобы получить html-кодировку или избежать ее. Мое приложение работает в режиме среднего доверия, которое должно быть выполнено.

Я бы сказал, что искра достаточно зрелая, чтобы ее можно было использовать в реальном развитии. Но не идеально.

Ответ 5

Я знаю, что на этот вопрос был дан ответ, и его спросили до того, как вышел Razor, но я бы выбрал Razor, если бы начал новый проект. У меня есть текущий проект с Spark, и я определенно согласен, что это лучший выбор для WebForms. Но поскольку пейзаж изменился, я бы выбрал что-то еще, если бы мне пришлось принять решение сегодня.

Причины

Главный разработчик Spark был нанят Microsoft (возможно, работает над Razor)
Последняя стабильная сборка для Spark на сегодняшний день составляет почти один год.
Синтаксис довольно похож.
Очертить поддержку. При создании веб-страниц для меня очень важно иметь возможность свернуть разделы html, Razor поддерживает это, а Spark не делает.

Я не покупаю аргумент о том, что у Razor приоритеты неправильны. Говорят, что по умолчанию Razor - это код, а затем некоторая разметка, а Spark - противоположное. Я согласен с этим доводом в ограниченной степени; инструменты существуют для обоих движков просмотра либо с отсутствием кода, либо с кодовым представлением. Это до парня, который в конечном итоге печатает его.