Отделение логики от представления: имена переменных HTTP?

Question

Это, вероятно, можно считать академическим вопросом, а не вопросом реального мира, но отбросим его, чтобы посмотреть, есть ли у кого-нибудь какие-нибудь великие идеи! Мы все знаем, что держать бизнес-логику приложения отдельно от презентации - это хорошая идея (я смотрю на веб-приложения), но между бизнес-логикой должно быть понимание того, какие HTTP-переменные ожидать (и затем обработать) и имена переменных, которые отправляются уровнем представления.

Это просто вопрос сообщить дизайнеру, какие имена переменных использовать в шаблоне? Шаблон не должен знать, что такое имена переменных (если только они не используются для селекторов JS / CSS), так почему они должны быть там «жестко закодированы». Или бизнес-логика должна помещать имена в переменные для распечатки? Еще один уровень сложности для шаблонов?

У кого-нибудь есть опыт или мысли о том, как с этим бороться?

Спасибо, Allan

Answer 1

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

Даже у самых способных дизайнеров инструменты, которые они используют, не позволяют решить проблему.

Подход, который мы в конечном итоге выбрали, заключался в том, что разработчики будут предоставлять примеры фрагментов HTML, которые дизайнеры затем будут строить вокруг страниц, а затем разработчики будут заменять фрагменты динамически генерируемым контентом и очищать таблицы стилей, объединяя любые занятия.

Это было самое прагматичное решение, которое мы могли найти.

С

Answer 2

Мои мысли ... Я думаю, это зависит от разработчика. Всякий раз, когда я создаю приложения, я, как вы предложили, разделяю бизнес-логику и логику представления и обычно определяю ViewModel. Затем viewModel становится контрактом между бизнес-логикой и представлением. Это позволяет обеим командам (разработчикам пользовательского интерфейса и бизнес-логики) развиваться независимо и, конечно, позволяет легко тестировать и т. Д.

Я ценю, что существуют различные подходы к рассмотрению логической разделенности, но благодаря опыту, если вы сможете определить контракт между двумя (в какой бы форме он ни находился в зависимости от того, какой шаблон вы используете), это облегчает разработку, особенно когда отдельные команды строят отдельные компоненты.