Должен ли HTML сосуществовать с кодом?

Как правило, лучше хранить презентацию (HTML) отдельно от логики ("внутреннего" кода). Таким образом, ваш код отделен от других, и его легче поддерживать.

Это ненадежно и небезопасно. Но люди делают это без последствий. Я бы предпочел использовать DOM или, как минимум, классы, предназначенные для написания HTML с использованием семантики безопасного типа. Кроме того, не все так хорошо смешивать пользовательский интерфейс с логикой ...

Пока ваш код написания HTML отделен от логики вашего приложения, и HTML гарантированно каким-то образом правильно сформирован, все должно быть в порядке.

Единственный код, который следует смешивать на страницах, основанных на разметке (т. Е. Тех, которые содержат буквальный HTML), - это код, используемый для форматирования HTML (например, цикл для записи списка).

Есть компромиссы, вставляете ли вы код вместе с HTML или используете чистый код для вывода HTML с использованием строковых литералов в кавычках.

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

Если мне нужны методы, генерирующие HTML, я обычно изолирую их в классе HtmlHelpers. Таким образом вы сохраните уровень разделения немного. Платформа ASP.NET MVC Framework делает это довольно успешно.

Если я правильно понимаю вопрос, вы спрашиваете, стоит ли смешивать разметку с внутренним кодом. Нет. Хотя это обычно и делается, это все еще плохая идея.

Вам следует ознакомиться с парадигмой MVC, а также с существующими вопросами по этому поводу, такими как Как лучше всего перенести существующее грязное веб-приложение на элегантный MVC? и Лучшие практики для рефакторинга классического ASP?.

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

Даже если вы думаете, что это вам не нужно сейчас, всегда есть хороший шанс, что вам это понадобится позже. Возможно, вы хотите выводить в формате, отличном от HTML, или вам нужно другое представление для одних и тех же данных. Обычно у вас есть потребность в этих вещах в будущем, поэтому лучше использовать их с самого начала.

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

Например, шаблоны будут содержать циклы и условные выражения. Кроме того, у вас, вероятно, будет библиотека специфичных для HTML подпрограмм, таких как печать списка <option> на основе объекта списка.

Представьте, что вы пишете приложение с двумя режимами вывода: HTML и что-то еще. Как бы вы это написали, чтобы избежать дублирования кода? Это, вероятно, укажет вам правильное направление.

Ненавижу, когда разработчики печатают () кучу html. Это совершенно не нужно и выглядит некрасиво в любом текстовом редакторе, который показывает строки вывода / вывода красным цветом.

HTML-код, составляющий представление, должен каким-то образом быть отправлен в браузер. В .net каждый серверный элемент управления создает собственную разметку HTML как часть жизненного цикла страницы. Так что да, можно использовать HTML в коде на стороне сервера.

Возможно, вам стоит попробовать следовать шаблону ASP.net. Создайте группу элементов управления, которые представляют элементы пользовательского интерфейса и возложат на них ответственность за создание собственного HTML-кода в зависимости от их состояния.

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

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

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

Чтобы повторить свою позицию из других вопросов, использование некоторой управляющей логики (условных выражений, циклов) в HTML для ее построения - это нормально. НЕ выполняйте обработку данных или бизнес-логику в HTML. Вы должны быть дисциплинированными, но оно того стоит. Обслуживание будет намного проще, если ваши задачи (например, логика и отображение) разделены.

В идеале вы стремитесь к разделение проблем между кодом вашей презентации (UI) и кодом домена (бизнес-логика).

Причина, по которой вам следует избегать объединения этих двух проблем (в любом направлении), проста ...

У вас будет только часть кода одна причина изменить. будь то структурные / стилистические изменения в вашем html-дизайне или изменение бизнес-правил, вам нужно внести изменения только в одном месте.

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

1. Пробую избегайте использования кода для печати HTML "напрямую". Сложно поддерживать, редактировать, добавлять стили и т. д. В некоторых случаях, например, создание HTML-сообщения электронной почты в коде, я создаю текстовый файл или HTML-файл с такими маркерами, как, [имя], [проверочный код] и т. д. Я загружаю это из кода и замените эти маркеры. Таким образом, вы можете редактировать стиль письма без повторной компиляции кода. Я считаю, что разделение «презентации» и «логики» является хорошей практикой.
2. Смешивание кода в HTML, как правило, не является хорошей практикой. по тем же причинам, что и в №1. Однако я использую код в HTML для таких вещей, как простые динамические строки, которые отображаются несколько раз на странице или страницах. Я думаю, что это лучше, чем создавать несколько серверных элементов управления для установки одинаковых точных значений. Поскольку это не «логика» кода, смешанная с HTML, я думаю, что это нормально.