Встраивание HTML-кода в хранимые процедуры - PullRequest
4 голосов
/ 30 октября 2008

У нас, похоже, есть несколько разработчиков, которые думают, что создание хранимых процедур, выкладывающих код HTML или Javascript, является законной вещью. На мой взгляд, это в конечном итоге злоупотребление моделью разделения интересов. Делает ли что-то подобное, что люди часто видели, как делают люди?

Ответы [ 9 ]

4 голосов
/ 30 октября 2008

Yucko. Есть несколько вопросов:

  • Не могу «оформить» приложение - перейдите к совершенно новой презентации, такой как Flex, настольные формы и т. Д.
  • Вы не позволяете графическим дизайнерам или экспертам по пользовательскому интерфейсу работать в продуктивной для них среде.
  • Если вы смешиваете свое хранилище HTML (некоторые в шаблонах, некоторые в БД, некоторые в коде приложения), абсолютно ужасно отслеживать проблемы с пользовательским интерфейсом.
  • Нет IDE DOM / проверка макета
  • Вы не можете просмотреть или создать прототип без запуска БД.
3 голосов
/ 30 октября 2008

если это сделано случайно, это, вероятно, является нарушением принципа разделения задач по слоям

с другой стороны, sprocs, специально написанные для генерации html из информации базы данных, в некоторых случаях могут быть очень легитимными и эффективными, особенно для высокодинамичных веб-сайтов с мягким кодированием, то есть когда часть структуры веб-сайта кодируется в базе данных или где сама база данных содержит фрагменты HTML ...

2 голосов
/ 30 октября 2008

ужасно неправильно! Просто мое мнение, хотя.

1 голос
/ 30 октября 2008

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

На момент запуска проекта в Oracle не было поддержки для отдельного сервера веб-приложений - все прошло через PL / SQL.

Иногда тебе просто нужно использовать что ты получил.

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

1 голос
/ 30 октября 2008

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

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

Единственное исключение будет, если ваша база данных фактически хранит Javascript или HTML, которые были отредактированы в другом месте, например, как часть CMS.

1 голос
/ 30 октября 2008

Utlimate нет-нет. Помимо всех предыдущих проблем, таких как безопасность, низкая связь и многоуровневость, что происходит, когда ваша компания хочет синдицировать контент, передавать его на мобильные устройства (wap и т. Д.), Использовать его в текстовых электронных письмах или распечатывать и т. Д.

0 голосов
/ 30 октября 2008

Да, я видел, что многие люди делают это, к сожалению. Хотя ты прав: это мерзко.

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

Если негодяи не убеждены в таких мольбах о здравомыслии, вы можете поймать их по соображениям безопасности. Функциональность уровня базы данных в хранимых процедурах вряд ли знает, как экранировать текст для вывода в HTML или JS-string-literal, что приводит к очень вероятным хакерским инъекциям, приводящим к атакам XSS. Например, если пользователь называет себя «Brian von steal (document.cookie) » и это грубо объединяется в результат HTML хранимой процедуры ...

0 голосов
/ 30 октября 2008

Самоочевидное нарушение принципа «слабая связь, высокая когезия».

Я не могу представить, как они предложили бы применить форматирование CSS к такому зверю.

0 голосов
/ 30 октября 2008

Это классическая ошибка новичка.

Если вам нужно поставить разметку в выходных данных SP, вы должны хотя бы использовать собственную стандартизированную кодировку, а затем приложение должно обработать ее в HTML / Javascript.

Например

"<javascriptpopup>[outputuotputoutput]</javascriptpopup>"

или

"<prettyfont>[outputuotputoutput]</prettyfont>"
...