ASP.NET MVC Spark view engine для дизайнеров, им нравится?

Question

Я нахожусь в процессе создания большого проекта Mpc asp.net и у меня есть вопрос, касающийся механизма рендеринга по умолчанию, в отличие от механизма MVC Spark в контексте для дизайнеров.

Я все за то, чтобы уменьшить мой суп из меток, и вижу, что двигатель зажигания аккуратный, очень аккуратный, и я, например, приветствовал бы это. Однако есть ли у кого-то опыт / мнения относительно того, принял ли их команда дизайнеров это или против?

Моя команда дизайнеров еще не разработала с использованием фреймворка Mvc, поэтому им придется изучить стандартный или искровой движок.

Кто-нибудь может прокомментировать?

Answer 1

Ваша команда разработчиков вообще не должна иметь никаких знаний о движке представлений. Они должны знать только о конечном продукте из движка представления (то есть HTML, CSS и Javascript, который выводится).

Ваши дизайнеры могут создавать шаблоны из простого старого HTML и CSS, даже не увидев ни одной строки кода движка рендеринга. Вам просто нужно указать им места в шаблоне, в который вы собираетесь добавить контент.

Смысл CSS / HTML-шаблонов в том, чтобы обеспечить разделение между дизайнером и разработчиком. Это позволяет отправлять эти шаблоны в дизайнерский цех. Вы не хотите, чтобы дизайнерский магазин связывался с вашим кодом разработки.

Дизайнер также предоставит вам набор стилей текста: h1, h2, h3, p и т. Д. Вы сможете подключать эти стили везде, где они нужны, в шаблонном коде движка рендеринга для достижения желаемых эффектов. Если вы хотите, вы можете позволить дизайнеру диктовать некоторые правила о макете и использовании этих стилей, но ваша задача - написать код, который отображает выходные данные в шаблоне дизайнера.

Итак, чтобы быть ясным, работа дизайнера заключается в создании HTML / CSS шаблона для вас (с образцом содержимого и стилями, чтобы вы оба могли адекватно видеть макет). Ваша задача - включить CSS / HTML, который дизайнер предоставляет вам, в код механизма представления.

Spark - это просто версия C # (или VB) с поддержкой HTML. При прочих равных условиях Spark будет проще для дизайнера, поскольку он меняет все <% { %> на HTML-эквиваленты. Но это предполагает, что дизайнеры будут писать код шаблона для механизма представления, которым они не будут.

Answer 2

Я знаю, что этот вопрос считается «ответом», но позвольте мне ответить с точки зрения «дизайнера» (мы называем его Front-end Developer).

У нас есть внутренняя команда (C #) и внешняя команда (HTML / CSS / Javascript), которая работает с приложениями .NET MVC. Spark - это гораздо более естественный способ просмотра HTML. Sparks добавляет естественный способ делать if и циклы, добавляя операторы if и each как атрибуты элемента HTML вместо циклов вне тегов HTML в тегах <%%>. Частицы также вызываются интуитивно понятным способом. будет включать частичный "_dashboard.spark".

В Spark вся разметка View выглядит как HTML, что, я думаю, очень важно для обеспечения работоспособности. Это также навязывает хорошие привычки MVC, сохраняя как можно больше логики вне разметки View. Команда разработчиков и создатель HTML-разметки, а затем разработчики могут добавить немного логики, чтобы начать генерацию контента.

С помощью Spark мы минимизировали проблему уродливого кода и разделили интерфейсную и внутреннюю работу, но при этом все еще текучие и поддерживаемые.

Answer 3

Не думаю, что дизайнеру нравится использовать Spark. Это слишком сложно использовать и смешивать некоторую логику, определение переменной. Дизайнер не должен знать какой-либо язык программирования. Я предпочитаю использовать Velocity View Engine (VTL), он прост в использовании и может заставить программиста отделить логику от внешнего интерфейса.