На огромном разгуле изучения с ASP.MVC 2 в последнее время и недавно раскрытый там существуют различные механизмы визуализации... Spark особенно привлек мое внимание, несколько вещей все же.
Каковы Ваши мысли? Я склоняюсь к, он, вероятно, не стоит того...
Отвечая на вопрос из трех частей по порядку...
Возможно, это хорошая идея - изучать новые вещи по одному. Особенно потому, что почти все примеры и учебники по MVC будут в синтаксисе WebForms. Тем не менее, лучше всего учиться на экспериментальном решении, а не на "реальном" проекте, так что после того, как вы почувствуете, что освоили концепции MVC, будет неплохо создать новую песочницу и попробовать несколько страниц MVC + Spark.
Производительность с точки зрения нагрузки на память или загрузки процессора, вероятно, не является самым важным фактором для всех, кроме самых крупных веб-сайтов... Влияние на время разработчика и дизайнера/творца может быть небольшим вначале, но оно кумулятивно и нелинейно. Небольшое упрощение на начальном этапе избавит вас от огромного количества боли в будущем, а "простой, понятный синтаксис" - это краеугольный камень предпосылок движка представления Spark".
Это очень верно. Полировка и совершенствование опыта - самая дорогая часть инструментария и современных IDE. Я думаю, именно поэтому большинство веб-стеков OSS начинаются с отличного редактора (cough TextMate cough) и развиваются оттуда. В Spark вы можете получить интеллисенс языка 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 , чтобы узнать что-нибудь другое
На самом деле, я стоял перед таким же выбором несколько месяцев назад, но для реального бизнес-приложения, а не для образовательных целей. Мой ответ - "to spark".
Конечно, есть некоторые хитрости вроде intellisense и include для предварительной компиляции. Но с моей точки зрения, преимущества более значительны. "Читабельность" представлений гораздо лучше в spark. Есть более элегантное разделение на части (опять же, мое личное мнение). Я также нахожу spark способ локализации сайта более естественным (MyView.spark, MyView.de.spark, MyView.de-DE.spark с автоматическим возвратом, и то же самое для мастер-макетов). Множество мелких удобств - больше всего я люблю ${} и !{}, чтобы получить html-кодировку или избежать ее. Мое приложение работает на среднем уровне доверия, будучи предварительно скомпилированным.
Я бы скорее сказал, что spark достаточно развит для использования в реальной разработке. Но не совершенен.