Полезно ли писать HTML с использованием StringBuilder в моем коде ASP.NET?

Question

Мне интересно услышать мнение других разработчиков о подходе, который я обычно использую. У меня есть веб-приложение, asp.net 2.0, c #.

То, что я обычно делаю для записи выпадающих списков, таблиц, элементов управления вводом и т. Д., - это код, использующий StringBuilder и записывающий что-то вроде sb.Append ("

Я не использую многие элементы управления .net, так как обычно пишу html в коде. Когда я хочу использовать jQuery или вызывать JavaScript, я просто помещаю этот вызов функции в мой тег sb.Append, например sb.Append ("td ... onblur = 'fnCallJS ()'.

Мне стало довольно удобно с таким подходом. Для доступа к данным я использую EntitySpaces.

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

---

Редактировать

После прочтения комментариев, похоже, мне стоит взглянуть на MVC. Я еще этого не сделал. Единственная нерешительность при этом заключается в том, что существующий проект является просто существующим. Как я объяснил, уже написано много кода, и трудно представить, что может повлиять на его изменение, преимущества этого и просто изучение того, что для этого потребуется.

Другая вещь, которую я убираю из комментариев, заключается в том, что мой код не должен включать большую часть кода sb.Append, тогда как теперь он заполнен множеством функций. Для меня это не грязно, но это потому, что я знаю, что делает каждая функция, и могу посмотреть на нее и увидеть, о, что выписывает x, y и z.

Я нередко просто делю div в части .aspx, а затем создаю .innerHtml этого с StringBuilder в коде позади.

Еще раз спасибо за комментарии. Я думаю, когда я читаю их.

Answer 1

Я обычно пишу HTML в коде позади.

Эта часть немного странная, и я не рекомендую ее для веб-форм. Если вы хотите сделать это, рассмотрите вместо этого проект mvc asp.net.

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

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

Answer 2

Я собираюсь выйти на конечность и предположить, что вы, возможно, пришли из "Классического" ASP (vbScript) или PHP фона.

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

Просмотрите различные потоки на веб-формах ASP.net и MCV, чтобы узнать, какие из них лучше всего подходят вашим проектам. MVC - не волшебное лекарство от всех болезней, но во многих отношениях оно может быть более привычным, если вы из классического ASP или PHP Backgound.

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

Answer 3

Бывают моменты, когда вам нужно сгенерировать какой-то HTML-код в своем коде, но в целом вы хотите оставить HTML-код там, где он есть, и он отделен от вашего кода. VS IDE - довольно хороший редактор HTML. Используйте это.

Answer 4

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

ВСЕ разметка находится в классах C #, и они создали объект StringBuilder для добавления всех строк HTML и JavaScript. Это сделало очень трудным чтение кода и просмотр того, что происходит, и что, если они захотят изменить разметку / дизайн внешнего интерфейса? Теперь у меня на руках куча работы по переориентации всей разметки в классах, когда было бы намного проще изменить страницы .aspx и подключить модель данных к этим страницам.

По моему скромному мнению, я не могу найти вескую причину, чтобы оставить какую-то разметку в ваших классах / коде позади. Они только для логики. Кроме того, это затрудняет тестирование и отладку Javascript. Это мои два цента. K.

Answer 5

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

Answer 6

Если вы используете этот подход, вы должны перенести свои усилия по разработке в ASP.Net MVC. Принимая во внимание, что ASP.Net активно пытается абстрагировать HTML, CSS, JavaScript и т. Д. С помощью веб-элементов управления, ASP.Net MVC построена вокруг парадигмы непосредственного управления самой разметкой (хотя, возможно, это может быть наименьшим из различий между два - вы должны обязательно прочитать его, чтобы хотя бы знать альтернативы, даже если в конечном итоге вы будете использовать ASP.Net).

В противном случае то, что вы делаете, работает, если все сделано правильно (хотя вы будете бороться с фреймворком весь путь), хотя я бы рекомендовал вместо этого использовать StringWriter . Он использует StringBuilder для внутреннего использования, поэтому характеристики производительности между ними одинаковы, но семантика более соответствует остальной части платформы .Net (например, Write vs. Append).

Answer 7

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

Или, возможно, более подходящим будет пользовательский элемент управления с разметкой на странице aspx и всем остальным в коде позади.

Answer 8

Большая проблема, с которой вы можете столкнуться, это может стать довольно грязной ... необходимость избегать всего "или возиться с возвратом каретки. Конечно, вы можете программировать вокруг этого, но что, если вы хотите скопировать / вставить код? Звучит как кошмар и НАМНОГО больше работы, чем стоит.