Les procédures stockées violent-elles la séparation à trois niveaux?
Certains de mes collègues m'ont dit que le fait d'avoir une logique métier dans les procédures stockées dans la base de données viole l'architecture de séparation à trois niveaux, car la base de données appartient à la couche de données tandis que les procédures stockées sont une logique métier.
Je pense que le monde serait un endroit très sombre sans procédures stockées.
Violent-ils vraiment la séparation à trois niveaux?
Vos collègues associent architecture et implémentation.
L'idée derrière une application à plusieurs niveaux est simplement qu'elle est divisée en parties qui encapsulent certains types de traitement (stockage, logique métier, présentation) et communiquent entre elles à l'aide d'interfaces bien définies. Tout comme il est possible de faire avec succès des choses qui ressemblent à une programmation orientée objet dans des langages non orientés objet, il est possible de faire de même avec plusieurs niveaux dans un environnement, comme un serveur de base de données. Ce que l'un ou l'autre de ceux qui ont réussi a en commun est un besoin de soins, de discipline et de compréhension des compromis impliqués.
Examinons une application à trois niveaux où deux des niveaux ont été mis en œuvre sur une base de données:
- Niveau de données: Consiste en tables de base de données accessibles à l'aide des quatre opérations de table standard (
INSERT,UPDATE,DELETEetSELECT) . - Niveau logique: Se compose de procédures stockées qui implémentent uniquement la logique métier et accèdent au niveau de données en utilisant uniquement les méthodes décrites ci-dessus.
- Niveau Présentation: Se compose d'un serveur Web exécutant du code qui accède au niveau logique en effectuant uniquement des appels de procédure stockée.
Il s'agit d'un modèle parfaitement acceptable, mais il s'accompagne de certains compromis. La logique métier est implémentée d'une manière qui lui donne un accès rapide et facile au niveau de données et peut permettre de faire des choses qui devraient être effectuées "à la dure" par un niveau logique en dehors de la base de données. Ce que vous abandonnez, c'est la possibilité de déplacer facilement l'un ou l'autre niveau vers une autre technologie et une mise en œuvre sans soucis (c'est-à-dire que vous devez faire très attention à ce que les niveaux n'utilisent pas les installations disponibles dans la base de données mais en dehors de leurs interfaces définies) .
La question de savoir si ce genre de chose et les compromis qu'elle entraîne sont acceptables dans une situation donnée est une question que vous et vos collègues devez déterminer en utilisant votre jugement.
Les procédures stockées sont suffisamment puissantes pour vous permettre de coder une violation de la séparation à trois niveaux en intégrant la logique métier dans la couche SGBDR. Cependant, c'est votre décision, pas une faille inhérente aux procédures stockées. Vous pouvez limiter vos SP pour répondre aux besoins de votre couche de données, tout en conservant votre logique d'application dans la couche d'application de votre architecture.
Il existe une exception rare mais importante à la règle de séparation, lorsque vous avez besoin de procédures stockées (en particulier, un groupe de déclencheurs) pour contenir la logique métier. Cela se produit lorsque votre application doit produire un grand nombre d'agrégations de données à la volée qui touchent des millions de lignes. Dans de tels cas, des déclencheurs peuvent être configurés pour maintenir des données pré-agrégées pour l'utilisation de la couche métier. Cela ne devrait être fait que dans les situations où, sans pré-agrégation, votre application serait trop lente.
Les conseils d'Atwood de 2004 sonnent encore aujourd'hui, mais nous bénéficions désormais également de l'ORM.
http://blog.codinghorror.com/who-needs-stored-procedures-anyways/
Les procédures stockées doivent être considérées comme un langage d'assemblage de base de données: à utiliser uniquement dans les situations les plus critiques en termes de performances. Il existe de nombreuses façons de concevoir une couche d'accès aux données solide et hautement performante sans recourir aux procédures stockées; vous réaliserez de nombreux avantages si vous vous en tenez au SQL paramétré et à un environnement de développement cohérent unique.
Bref résumé: Cela dépend vraiment de votre utilisation des procédures stockées et des exigences commerciales.
Il existe un certain nombre de projets qui utilisent une architecture à trois niveaux et, selon la nature des besoins de l'entreprise, il peut être nécessaire de déplacer certaines opérations vers un niveau de données .
En parlant de terminologie, en termes généraux, ces niveaux sont décrits comme suit:
- Le niveau de présentation , ou couche de services aux utilisateurs - permet à un utilisateur d'accéder à l'application.
- Le niveau intermédiaire , ou couche de services métier, se compose de règles métier et de règles de données.
- Le niveau de données , ou couche de services de données, interagit avec les données persistantes généralement stockées dans une base de données ou dans un stockage permanent.
Habituellement, pour l'architecture donnée, le niveau intermédiaire ou couche de services métier, se compose de règles métier et de règles de données. Cependant, il est parfois très important de déplacer des opérations de base et/ou des règles de données lourdes à effectuer dans le niveau de données - via un ensemble de procédures stockées.
Les avantages des conceptions à trois niveaux sont les suivants:
Pendant le cycle de vie d'une application, l'approche à trois niveaux offre des avantages tels que la réutilisabilité, la flexibilité, la gérabilité, la maintenabilité et l'évolutivité. Vous pouvez partager et réutiliser les composants et services que vous créez, et vous pouvez les distribuer sur un réseau d'ordinateurs selon vos besoins. Vous pouvez diviser des projets volumineux et complexes en projets plus simples et les affecter à différents programmeurs ou équipes de programmation. Vous pouvez également déployer des composants et des services sur un serveur pour vous aider à suivre les modifications et les redéployer à mesure que la base d'utilisateurs, les données et le volume de transactions de l'application augmentent.
Il s'agit donc en réalité d'une approche fondée sur des cas qui a elle-même des compromis. Cependant, les directives de conception Microsoft de modèle d'architecture à trois niveaux recommande de conserver votre logique métier au niveau intermédiaire.
Tier signifie en fait une machine différente, couche signifie une séparation logique différente. Avec les procédures stockées, vous avez la couche de données et (au moins une partie de) la couche de logique métier dans le même niveau. Mettre la logique métier dans les procédures stockées viole l'architecture à 3 fatigués mais on peut se demander si elle viole une architecture à 3 couches; une chose sûre est que ce n'est pas un bon exemple de séparation des préoccupations.
Une couche est un mécanisme de structuration logique des éléments qui composent votre solution logicielle; un niveau est un mécanisme de structuration physique de l'infrastructure système. ( Référence )
À mon avis, la création d'une logique métier dans la base de données présente deux problèmes majeurs:
Code et bibliothèques: vous trouverez moins de programmeurs capables de programmer en SQL, PL/SQL, TSQL etc. qu'en C #, Java etc. Les langages de programmation ont également l'avantage de grands IDE, grands bibliothèques et frameworks.
Évolutivité horizontale: la seule façon de faire évoluer votre système est de changer le serveur physique sur lequel la base de données est plus puissante, ce qui est assez cher (un serveur avec 64 Go de RAM); les bases de données relationnelles évoluent horizontalement très mal, et même à des dépenses plus importantes. Alors que, avec la logique métier dans un serveur OO, vous pouvez assez bien évoluer horizontalement en plaçant le serveur sur de nombreux nœuds (dans Java de nombreux serveurs d'applications prennent en charge cela).