Nous semblons avoir quelques développeurs ici qui pensent que créer des procédures stockées qui crachent du code HTML ou Javascript est une chose légitime à faire. Dans mon esprit, c'est l'abus ultime du modèle de séparation des préoccupations. Est-ce que faire quelque chose comme ce peuple a souvent vu les gens faire?Incorporation du code html dans les procédures stockées
Horriblement faux! Juste mon avis cependant.
Il s'agit d'une erreur novice classique.
Si vous devez mettre un balisage dans la sortie SP, vous devez au moins utiliser votre propre encodage standardisé et demander à l'application de le traiter en HTML/Javascript.
Par exemple
"<javascriptpopup>[outputuotputoutput]</javascriptpopup>"
ou
"<prettyfont>[outputuotputoutput]</prettyfont>"
Yucko. Il y a quelques problèmes:
Une violation évidente du principe «faible couplage, haute cohésion».
Je ne peux pas imaginer comment ils suggéreraient d'appliquer le formatage CSS à une telle bête.
si cela se fait au petit bonheur, il est probablement une violation de la séparation des préoccupations principales des couches
d'autre part, sprocs expressely écrit pour générer html à partir d'informations de base de données peut, dans certains cas, être très légitime et efficace, esp. pour les sites Web hautement codés et dynamiques, c'est-à-dire où une partie de la structure du site est codée dans la base de données ou où la base de données elle-même contient des fragments HTML ...
Oui, j'ai vu beaucoup de gens le faire, malheureusement. Tu as raison: c'est vil.
Habituellement, les problèmes de séparation des couches surviennent lorsque deux couches adjacentes se mélangent: vous obtenez une logique métier dans la couche de base de données ou une logique de présentation dans la couche de gestion. Mais cela saute une couche entièrement, mettant des miles de présentation côté utilisateur d'où il appartient! Obligé d'être une horreur impossible à maintenir.
Si les canailles ne sont pas convaincues par ces arguments en faveur de la santé mentale, vous pourriez être en mesure de les attraper pour des raisons de sécurité. La fonctionnalité de couche de base de données dans les procédures stockées a peu de chance de savoir comment échapper du texte en sortie au format HTML ou JS-string-literal, ce qui aboutit à des attaques de scripts très probables menant à des attaques XSS. Par exemple, si un utilisateur s'appelle lui-même "Brian von < script> steal (document.cookie) </script>" et que cela est grossièrement concaténé dans un résultat HTML de procédure stockée ...
Utlocat no-no. Mis à part toutes les préoccupations précédentes comme la sécurité, le faible couplage et la superposition, que se passe-t-il lorsque votre entreprise veut syndiquer le contenu, le diffuser sur des appareils mobiles (wap, etc.), l'utiliser dans des courriels ou imprimer des textes ...
Je ne pense pas que le problème soit la séparation des préoccupations, car les sprocs manquent d'outils pour le faire correctement.
De même, toute personne rencontrant ce code aura des problèmes pour le déterminer, et il sera très difficile de contrôler la source, d'intégrer et de tester l'unité. La seule exception serait que votre base de données stocke du Javascript ou du HTML édité ailleurs, dans le cadre d'un CMS par exemple.
J'ai survécu à un travail dans un magasin où l'ensemble de l'application a émis tout le HTML, heureusement en utilisant des références aux CSS/JS externes.
Au moment du démarrage du projet, Oracle ne disposait d'aucun support pour un serveur Web/d'application séparé - tout est passé par PL/SQL.
Parfois vous devez juste utiliser whatcha got. Cela dit, je ne crois pas qu'il existe une excuse pour générer des artefacts de niveau View à partir des procédures stockées dans l'un des DB modernes ou des architectures d'application.