Встраивание html-кода в хранимые процедуры

Ужасно неправильно! Но это только мое мнение.

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

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

Например

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

или же

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

Юко. Есть несколько проблем:

• Невозможно "обшить" приложение - перейдите к совершенно новой презентации, такой как Flex, настольные формы и т. д.
• Вы не позволяете графическим дизайнерам или специалистам по пользовательскому интерфейсу работать в продуктивной для них среде.
• Если вы смешиваете свое хранилище HTML (некоторые в шаблонах, некоторые в базе данных, некоторые в коде приложения), совершенно ужасно отслеживать проблемы пользовательского интерфейса.
• Нет IDE DOM / проверки макета
• Вы не можете выполнить предварительный просмотр или прототип без запуска db.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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