Spark или не Spark?

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

1. Вероятно, будет хорошей идеей изучать новые вещи по одному. Тем более, что почти все примеры и руководства MVC будут в синтаксисе WebForms. Тем не менее - лучше учиться на экспериментальном решении, а не на вашем «реальном» проекте, поэтому после того, как вы почувствуете, что у вас есть концепции MVC, неплохо создать новую песочницу и попробовать несколько страниц MVC + Spark.

2. Производительность с точки зрения нехватки памяти или использования процессора, вероятно, не является самым важным фактором для всех, кроме крупнейших веб-сайтов ... Влияние на разработчика, дизайнера / креативщика, время может сначала быть небольшим, но оно накапливается и нелинейно . Небольшое упрощение заранее избавит вас от лишних хлопот в будущем, а «простой и понятный синтаксис» является краеугольным камнем концепции движка Spark View.

3. Это очень верно. Полировка и усовершенствование опыта - самая дорогая часть инструментов и современных IDE. Я думаю, что именно поэтому большинство веб-стеков OSS начинаются с отличного редактора (кашляет TextMate кашляет) и с этого момента продвигаются вверх. С помощью Spark вы можете получить intellisense на языке csharp, но это явно низкий уровень поддержки инструментов.

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

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

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

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

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

Spark значительно ближе к чистому HTML, чем ASP.net

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

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

Собственно, несколько месяцев назад я столкнулся с таким же выбором, но для реального бизнес-приложения, а не для образовательных целей. Мой ответ - «зажечь».

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

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

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

Причины

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

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