Les procédures stockées violent-elles la séparation à trois niveaux?

Certains de mes collègues m'ont dit que la logique métier dans les procédures stockées de la base de données enfreignait l'architecture de séparation à trois niveaux, car la base de données appartenait à la couche de données, alors que les procédures stockées étaient de la logique métier.

Je pense que le monde serait un endroit très sombre sans procédures stockées.

Est-ce qu'ils violent vraiment la séparation à trois niveaux?

Vos collègues associent architecture et implémentation.

L'idée à la base d'une application multiniveau est simplement de diviser celle-ci en plusieurs parties qui encapsulent certains types de traitement (stockage, logique métier, présentation) et communiquent entre elles via des interfaces bien définies. Tout comme il est possible de réussir des choses qui ressemblent à la programmation orientée objet dans des langages non orientés objet, il est possible de faire la même chose avec plusieurs niveaux au sein d'un même environnement, tel qu'un serveur de base de données. Ce qui est commun à tous ceux qui réussissent, c'est un besoin de soin, de discipline et une compréhension des compromis en jeu.

Examinons une application à trois niveaux dans laquelle deux des niveaux ont été implémentés dans une base de données:

• Niveau données: Consiste de tables de base de données accessible en utilisant les quatre opérations de table standard ( INSERT, UPDATE, DELETEet SELECT).
• Niveau logique: se compose de procédures stockées qui implémentent uniquement la logique métier et accèdent au niveau données en utilisant uniquement les méthodes décrites ci-dessus.
• Présentation Niveau: consiste en un code d'exécution de serveur Web qui accède au niveau logique en effectuant uniquement des appels de procédure stockée.

C'est un modèle parfaitement acceptable, mais il s'accompagne de compromis. La logique métier est mise en œuvre de manière à lui donner un accès rapide et facile au niveau données et peut permettre d'effectuer des tâches qui devraient être effectuées "à la dure" par un niveau logique situé 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 un autre élément technologique et une mise en œuvre simple (vous devez faire très attention à ce que les tiers n’utilisent pas les installations disponibles dans la base de données mais en dehors de leurs interfaces définies). .

Que ce soit ce genre de choses et les compromis qu’il apporte soient acceptables dans une situation donnée, c’est quelque chose 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, il s’agit de votre décision et non d’un défaut inhérent aux procédures stockées. Vous pouvez limiter vos SP à répondre aux besoins de votre couche de données tout en conservant la logique de votre 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 d'un groupe de déclencheurs) pour contenir la logique métier. Cela se produit lorsque votre application doit générer de nombreuses 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 conserver des données pré-agrégées pour une utilisation de la couche de gestion. Cela ne devrait être fait que dans des situations où, sans pré-agrégation, votre application serait trop lente.

Le conseil d'Atwood de 2004 sonne vrai encore aujourd'hui, à présent seulement, nous bénéficions é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 obtiendrez 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 de l’entreprise.

Un certain nombre de projets 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, ces niveaux sont décrits comme suit:

• Le niveau présentation , ou couche de services utilisateur, permet à un utilisateur d'accéder à l'application.
• Le niveau intermédiaire , ou couche de services métier, est composé 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 stockées de manière permanente.

Généralement, pour l’architecture donnée, la couche de services intermédiaires ou d’entreprise comprend des règles de gestion et 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 dans le niveau données - à travers un ensemble de procédures stockées.

Les avantages des conceptions à trois niveaux sont les suivants:

Durant le cycle de vie d'une application, l'approche à trois niveaux offre des avantages tels que la réutilisabilité, la flexibilité, la facilité de gestion, 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 suivre le rythme des modifications. Vous pouvez également 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 vraiment d’une approche fondée sur la jurisprudence qui comporte des compromis en soi. Toutefois, les directives de conception Microsoft du modèle d' architecture à trois niveaux recommandent de conserver votre logique métier au niveau intermédiaire.

Tier signifie en réalité 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) la couche de logique applicative dans le même niveau. L'insertion de la logique métier dans les procédures stockées constitue une violation de l'architecture à 3 contraintes, mais on peut se demander si elle enfreint une architecture à 3 couches. Une chose est sûre: ce n'est certainement pas un bon exemple de séparation des préoccupations.

Une couche est un mécanisme de structuration logique des éléments constituant votre solution logicielle. un niveau est un mécanisme de structuration physique de l'infrastructure système. ( Référence )

À mon avis, la construction de la logique métier dans la base de données pose deux problèmes majeurs:

1. Code et bibliothèques: vous constaterez que moins de programmeurs sont capables de programmer en SQL, PL / SQL, TSQL, etc. qu'en C #, Java, etc. Les langages de programmation ont également l'avantage de créer des IDE, des bibliothèques et des frameworks de grande qualité.

2. Évolutivité horizontale: la seule façon de faire évoluer votre système consiste à changer le serveur physique sur lequel se trouve la base de données avec un système plus puissant, ce qui est plutôt coûteux (un serveur doté de 64 Go de RAM); Les bases de données relationnelles ont une échelle horizontale très mauvaise, et même avec des dépenses plus importantes. Cependant, avec la logique métier dans un serveur construit en mode OO, vous pouvez très bien évoluer horizontalement en plaçant le serveur sur de nombreux nœuds (en Java, de nombreux serveurs d'applications le prennent en charge).

Nous avons eu ce débat dans notre bureau il y a quelques temps, je favorisais le développement de base de données, j'ai un avis suivant à ce sujet

1. Si vous utilisez Oracle Database, vous devez utiliser autant que possible PL / SQL, car les entreprises qui investissent resteront sûrement fidèles à Oracle au moins 10 ans à compter de maintenant. Hier, dans les applications, vous utilisiez Oracle Forms, aujourd'hui, des formulaires Web .net, puis MVC, puis demain, vous utiliserez angularjs et aurez simplement besoin d'un apis reposant. Si votre base de données contient le maximum de logique, vous pouvez facilement migrer vers les nouvelles technologies front-end.
2. Le développement de la base de données est très rapide et très efficace en termes de performances. Juste pour vous donner une perspective. Dans notre projet, il y avait 7 développeurs d'applications et un développeur de base de données, et 80% de la logique était dans la base de données.
3. Si vous utilisez oracle, vous pouvez utiliser des utilitaires pour convertir directement vos procédures de base de données en Ap full.

L’argument le plus puissant que les développeurs d’applications lui donnent est que la logique d’entreprise doit être indépendante de la base de données pour que vous puissiez facilement la modifier. Je pense que si une entreprise utilise oracle pour savoir pourquoi elle optera pour une autre technologie, les chances d'obtenir une logique d'application obsolète sont plus probables. Le problème est principalement lié aux nouveaux talents de la base de données qui manque, principalement aux types de site Web simples où ils utilisent mysql ou sqlserver. Ces types deviennent alors des responsables principaux et ont un attachement émotionnel avec la couche d’application :) ils ne veulent même pas comprendre ni débattre.