Logique d'entreprise: base de données ou couche d'application

https://stackoverflow.com/questions/119540

02-07-2019
|

Question

La vieille question. Où devez-vous placer votre logique métier, dans la base de données sous forme de procédures stockées (ou de packages) ou dans le niveau applicatif / intermédiaire? Et plus important encore, pourquoi?

Supposez que l'indépendance de la base de données n'est pas un objectif.

La solution

Mettez suffisamment de logique métier dans la base de données pour vous assurer que les données sont cohérentes et correctes.

Mais n'ayez pas peur de dupliquer une partie de cette logique à un autre niveau pour améliorer l'expérience utilisateur.

Autres conseils

La maintenabilité de votre code est toujours une préoccupation majeure lors de la détermination de la logique métier.

Des outils de débogage intégrés et des IDE plus puissants facilitent généralement la maintenance du code de niveau intermédiaire par rapport au même code dans une procédure stockée. Sauf indication contraire, vous devez commencer par la logique métier dans votre application / niveau intermédiaire et non dans les procédures stockées.

Toutefois, lorsque vous vous adressez à la génération de rapports et à l'exploration / la recherche de données, les procédures stockées peuvent souvent être un meilleur choix. C’est grâce à la puissance des capacités d’agrégation / filtrage des bases de données et au fait que vous gardez le traitement très proche de la source des données. Mais ce n’est peut-être pas ce que la plupart considèrent de toute façon comme une logique métier classique.

Pour des cas très simples, vous pouvez placer votre logique métier dans des procédures stockées. Habituellement, même les cas simples ont tendance à se compliquer avec le temps. Voici les raisons pour lesquelles je ne mets pas de logique métier dans la base de données:

La logique métier de la base de données est étroitement liée à la mise en œuvre technique de la base de données. Le fait de modifier une table entraîne la modification d’un grand nombre de procédures stockées, ce qui entraîne de nombreux bogues et tests supplémentaires.

Généralement, l'interface utilisateur dépend de la logique métier pour des tâches telles que la validation. Le fait de placer ces éléments dans la base de données provoquera un couplage étroit entre la base de données et l'interface utilisateur ou, dans des cas différents, duplique la logique de validation entre ces deux applications.

Il sera difficile de faire fonctionner plusieurs applications sur la même base de données. Les modifications d'une application entraîneront la rupture des autres. Cela peut rapidement se transformer en cauchemar de maintenance. Donc, ça n'échelle pas vraiment.

De manière plus pratique, SQL n'est pas un bon langage pour implémenter la logique métier de manière compréhensible. SQL est idéal pour les opérations basées sur les ensembles mais il manque des constructions pour la "programmation dans le grand" il est difficile de maintenir de grandes quantités de procédures stockées. Les langages OO modernes sont mieux adaptés et plus flexibles pour cela.

Cela ne signifie pas que vous ne pouvez pas utiliser les procédures et les vues stockées. Je pense que c'est parfois une bonne idée de mettre une couche supplémentaire de procédures stockées et de vues entre les tables et les applications pour découpler les deux. De cette façon, vous pouvez modifier la présentation de la base de données sans changer d'interface externe, ce qui vous permet de refactoriser la base de données indépendamment.

C’est vraiment à vous de décider, tant que vous êtes cohérent .

Une bonne raison de la placer dans votre couche base de données: si vous êtes à peu près sûr que vos clients ne modifieront jamais leur base de données.

Une bonne raison de l'insérer dans la couche d'application: si vous ciblez plusieurs technologies de persistance pour votre application.

Vous devez également prendre en compte les compétences essentielles. Vos développeurs sont-ils principalement des développeurs de couche d’application ou principalement des types DBA?

Bien qu'il soit certainement avantageux de disposer de la logique applicative sur la couche application, j'aimerais souligner que les langages / cadres semblent changer plus fréquemment que les bases de données.

Certains des systèmes que je supporte ont traversé les interfaces utilisateur suivantes au cours des 10 à 15 dernières années: Servlet Oracle Forms / Visual Basic / Perl CGI / ASP / Java. La seule chose qui n'a pas changé - la base de données relationnelle et les procédures stockées.

Bien qu'il n'y ait pas une seule bonne réponse - cela dépend du projet en question, je recommanderais l'approche préconisée dans " Description basée sur le domaine n " par Eric Evans. Dans cette approche, la logique métier est isolée dans sa propre couche - la couche de domaine - située au-dessus de la ou des couches d'infrastructure, pouvant inclure votre code de base de données, et sous la couche d'application, qui envoie les demandes dans la couche de domaine. pour exécution et écoute pour confirmation de leur achèvement, conduisant efficacement la demande.

Ainsi, la logique métier est capturée dans un modèle qui peut être discuté avec ceux qui comprennent l’entreprise en dehors des problèmes techniques. Il devrait ainsi être plus facile d’isoler les modifications apportées aux règles métier elles-mêmes, les problèmes d’implémentation technique et le flux de l'application qui interagit avec le modèle métier (domaine).

Je vous recommande de lire le livre ci-dessus si vous en avez la chance, car il explique assez bien comment cet idéal pur peut être approché dans le monde réel du code et des projets réels.

L'indépendance de la base de données, que l'auteur de la question exclut en tant que considération dans ce cas, est l'argument le plus puissant pour supprimer la logique de la base de données. Le principal argument en faveur de l'indépendance de la base de données concerne la possibilité de vendre des logiciels à des entreprises ayant leur propre préférence pour un backend de base de données.

Par conséquent, je considérerais que le principal argument en faveur de la suppression des procédures stockées de la base de données est un argument commercial et non technique. Il peut y avoir des raisons techniques, mais également des raisons techniques pour les conserver: performances, intégrité et possibilité d'autoriser plusieurs applications à utiliser la même API, par exemple.

L'utilisation ou non des SP est également fortement influencée par la base de données que vous allez utiliser. Si vous ne tenez pas compte de l'indépendance de la base de données, votre expérience de l'utilisation de T-SQL ou de PL / SQL sera très différente.

Si vous utilisez Oracle pour développer une application, PL / SQL est un choix évident en tant que langage. Il est très étroitement couplé aux données, sans cesse amélioré, et chaque outil de développement correct va intégrer le développement PL / SQL à CVS ou à Subversion ou à d’autres.

L’environnement de développement Application Express d’Oracle basé sur le Web est même construit à 100% avec PL / SQL.

Tout ce qui affecte l'intégrité des données doit être placé au niveau de la base de données. D'autres éléments que l'interface utilisateur introduisent souvent des données dans, mettent à jour ou suppriment des données de la base de données, notamment des importations, des mises à jour en masse pour modifier un système de tarification, des correctifs, etc. Si vous devez vous assurer que les règles sont toujours suivies, définissez la logique par défaut. et déclencheurs.

Cela ne veut pas dire que ce n'est pas une bonne idée de l'avoir aussi dans l'interface utilisateur (pourquoi se donner la peine d'envoyer des informations que la base de données n'acceptera pas), mais ignorer ces choses dans la base de données est un désastre .

Si vous avez besoin de l'indépendance de la base de données, vous voudrez probablement placer toute votre logique métier dans la couche application, car les normes disponibles dans la couche application sont beaucoup plus répandues que celles disponibles dans la couche base de données.

Toutefois, si l'indépendance de la base de données n'est pas le facteur n ° 1 et que l'ensemble des compétences de votre équipe inclut de solides compétences en base de données, l'intégration de la logique métier dans la base de données peut s'avérer la meilleure solution. Vous pouvez demander aux utilisateurs de votre application d'effectuer des tâches spécifiques à l'application et à ceux de la base de données de s'assurer que toutes les requêtes volent.

Bien sûr, il existe une grande différence entre la capacité de générer une instruction SQL et le fait d’avoir "de solides compétences en bases de données". - Si votre équipe est plus proche de la première que de la dernière, alors insérez la logique dans l’application en utilisant l’un des Hibernés de ce monde (ou changez d’équipe!).

D'après mon expérience, dans un environnement d'entreprise, vous disposez d'une base de données cible unique et de compétences dans ce domaine. Dans ce cas, mettez tout ce que vous pouvez dans la base de données. Si vous vendez des logiciels, le coût des licences de base de données fera de l’indépendance de la base de données le facteur le plus important et vous implémenterez tout ce que vous pouvez dans le niveau application.

L’espoir que cela aide.

Il est aujourd'hui possible de soumettre à subversion votre code proc stocké et de le déboguer avec un bon support d’outil.

Si vous utilisez des procédures stockées combinant des instructions SQL, vous pouvez réduire le volume de trafic de données entre l'application et la base de données, réduire le nombre d'appels à la base de données et générer d'importants gains de performances.

Une fois que nous avons commencé à construire en C #, nous avons pris la décision de ne pas utiliser de procs stockés, mais maintenant nous transférons de plus en plus de code dans les procs stockés. Surtout le traitement par lots.

Cependant, n'utilisez pas de déclencheurs, utilisez des procs stockés ou de meilleurs packages. Les déclencheurs diminuent la maintenabilité.

Si vous placez le code dans la couche d'application, vous obtiendrez une application indépendante de la base de données.

Parfois, il est préférable d'utiliser des procédures stockées pour des raisons de performances.

Cela dépend (comme d'habitude) des exigences de l'application.

Les données ne contiennent que des données.

Les procédures stockées sont un cauchemar de maintenance. Ils ne sont pas des données et ils n'appartiennent pas à la base de données. La coordination sans fin entre les développeurs et les administrateurs de base de données n’est rien de plus que des frictions entre organisations.

Il est difficile de garder un bon contrôle de version des procédures stockées. Le code en dehors de la base de données est très facile à installer - lorsque vous pensez que vous avez la mauvaise version, vous ne faites qu’une SVN UP (peut-être une installation) et le retour de votre application à un état connu. Vous avez des variables d’environnement, des liens de répertoire et de nombreux contrôles d’environnement sur l’application.

Vous pouvez, avec de simples manipulations PATH , disposer de variantes de logiciels disponibles pour différentes situations (formation, test, assurance qualité, production, améliorations spécifiques au client, etc.)

Cependant, le code dans la base de données est beaucoup plus difficile à gérer. Il n’existe pas d’environnement approprié - pas de "PATH", de liens de répertoire ni d’autres variables d’environnement - permettant de contrôler de manière utilisable le logiciel utilisé; vous disposez d'un ensemble permanent de logiciels d'application liés globalement, bloqués dans la base de données et associés aux données.

Les déclencheurs sont encore pires. Ils sont à la fois un cauchemar de maintenance et de débogage. Je ne vois pas quel problème ils résolvent; ils semblent être un moyen de contourner des applications mal conçues où personne ne se soucierait pas d’utiliser correctement les classes disponibles (ou les bibliothèques de fonctions).

Alors que certaines personnes trouvent l’argument des performances convaincant, je n’ai toujours pas vu suffisamment de données de référence pour me convaincre que les procédures stockées sont rapides. Tout le monde a une anecdote, mais personne n’a de code côte à côte dans lequel les algorithmes sont plus ou moins identiques.

[Dans les exemples que j'ai vus, l'ancienne application était un gâchis mal conçu; Lorsque les procédures stockées ont été écrites, l'application a été restructurée. Je pense que le changement de conception a eu plus d’impact que le changement de plate-forme.]

La logique métier doit être placée en premier lieu dans l’application / le niveau intermédiaire. De cette façon, il peut être exprimé sous la forme d'un modèle de domaine, placé dans le contrôle de source, divisé ou combiné avec du code associé (modifié), etc. Il vous donne également une certaine indépendance vis-à-vis du fournisseur de base de données.

Les langues orientées objet sont également beaucoup plus expressives que les procédures stockées, ce qui vous permet de décrire plus facilement et plus facilement dans le code ce qui devrait se passer.

Les seules bonnes raisons de placer du code dans les procédures stockées sont les suivantes: si cela présente un avantage significatif et nécessaire en termes de performances ou si le même code commercial doit être exécuté par plusieurs plates-formes (Java, C #, PHP). Même si vous utilisez plusieurs plates-formes, il existe des alternatives telles que des services Web qui pourraient mieux convenir au partage de fonctionnalités.

D'après mon expérience, la réponse se situe quelque part dans un éventail de valeurs généralement déterminées par les compétences de votre organisation.

Le SGBD est une bête très puissante, ce qui signifie qu'un traitement approprié ou non-conforme apportera un grand bénéfice ou un grand danger. Malheureusement, dans trop d’organisations, l’attention principale est portée sur le personnel de la programmation; Les compétences en matière de dbms, en particulier les compétences de développement de requêtes (par opposition aux tâches administratives), sont négligées. Ce qui est exacerbé par le fait que la capacité d’évaluer les compétences en matière de dbms fait également probablement défaut.

Et peu de programmeurs comprennent suffisamment ce qu’ils ne comprennent pas à propos des bases de données.

D'où la popularité des concepts sous-optimaux, tels que Active Records et LINQ (pour introduire un biais évident). Mais ils sont probablement la meilleure solution pour de telles organisations.

Cependant, notez que les organisations très évoluées accordent une plus grande attention à l’utilisation efficace du datastore.

Il n’existe pas de bonne réponse autonome à cette question. Cela dépend des exigences de votre application, des préférences et des compétences de vos développeurs, ainsi que de la phase de la lune.

La logique métier doit être placée dans la couche application et non dans la base de données. La raison en est qu'une procédure stockée de base de données dépend toujours du produit de base de données que vous utilisez. Cette rupture est l’un des avantages du modèle à trois niveaux. Vous ne pouvez pas facilement passer à une autre base de données à moins de fournir une procédure stockée supplémentaire pour ce produit de base de données. d’autre part, il est parfois judicieux de placer la logique dans une procédure stockée pour optimiser les performances.

Ce que je veux dire, c'est que la logique métier doit être intégrée au niveau application, à quelques exceptions près (principalement pour des raisons de performances)

Les "couches" de l'application de gestion sont:

1. Interface utilisateur

Ceci implémente la vue de l'utilisateur professionnel sur le travail h (is / er). Il utilise des termes familiers à l'utilisateur.

2. Traitement en cours

C’est là que les calculs et la manipulation des données ont lieu. Toute logique métier impliquant le changement de données est implémentée ici.

3. Base de données

Cela pourrait être: une base de données séquentielle normalisée (le SGBD standard basé sur SQL); une base de données OO, stockant des objets encapsulant les données métier; etc.

Qu'est-ce qui se passe où

Pour accéder aux couches ci-dessus, vous devez effectuer l’analyse et la conception nécessaires. Cela indiquerait le meilleur moyen d'implémenter la logique métier: les règles d'intégrité des données et les problèmes de simultanéité / temps réel concernant les mises à jour des données seraient normalement implémentés aussi près que possible des données, de la même manière que les champs calculés, ce qui est un bon indicateur aux procédures stockées / déclencheurs, où l’intégrité des données et le contrôle des transactions sont absolument nécessaires.

Les règles commerciales impliquant la signification et l'utilisation des données seraient pour la plupart implémentées dans la couche Traitement, mais figureraient également dans l'interface utilisateur en tant que flux de travail de l'utilisateur, reliant les différents processus dans un ordre donné. qui reflète le travail de l'utilisateur.

Imho. Il existe deux problèmes contradictoires quant au choix de l'emplacement de la logique métier dans une application basée sur une base de données relationnelle:

maintenabilité
fiabilité

Re. maintenabilité: & nbsp; Pour permettre un développement futur efficace, la logique métier appartient à la partie de votre application la plus facile à déboguer et à contrôler les versions.

Re. fiabilité: & nbsp; En cas de risque important d'incohérence, la logique applicative appartient à la couche base de données. & nbsp; Les bases de données relationnelles peuvent être conçues pour vérifier les contraintes sur les données, par exemple. n'autorisant pas les valeurs NULL dans des colonnes spécifiques, etc. & nbsp; Lorsqu'un scénario se présente dans la conception de votre application où certaines données doivent se trouver dans un état spécifique trop complexe pour être exprimé avec ces contraintes simples, il peut être judicieux d'utiliser un déclencheur ou quelque chose de similaire dans la couche de base de données.

Les déclencheurs sont difficiles à tenir à jour, en particulier lorsque votre application est supposée s'exécuter sur des systèmes clients auxquels vous n'avez même pas accès. & nbsp; Mais cela ne veut pas dire qu’il est impossible de les suivre ou de les mettre à jour. & nbsp; Les arguments de S.Lott dans sa réponse selon lesquels c’est pénible et compliqué sont tout à fait valables; j’appuie cela et j’y suis allé également. & nbsp; Mais si vous tenez compte de ces limitations lors de la conception initiale de votre couche de données et que vous vous abstenez d'utiliser des déclencheurs et des fonctions pour des tâches autres que celles absolument nécessaires, il est facile de les gérer.

Dans notre application, la logique métier est en grande partie contenue dans la couche modèle de l'application, par exemple. une facture sait comment s'initialiser à partir d'une commande client donnée. & nbsp; Lorsqu'un ensemble d'éléments différents est modifié séquentiellement pour un ensemble complexe de modifications, nous les intégrons dans une transaction afin de maintenir la cohérence, au lieu d'opter pour une procédure stockée. & nbsp; Le calcul des totaux, etc. est effectué avec les méthodes de la couche de modèle. & nbsp; Mais lorsque nous devons dénormaliser quelque chose pour améliorer les performances ou insérer des données dans une table des "modifications" utilisée par tous les clients pour déterminer les objets à expirer dans leur mémoire cache de session, nous utilisons des déclencheurs / fonctions dans la couche de base de données pour insérer un élément. nouvelle ligne et envoyer une notification (Postgres listen / notify stuff) à partir de ce déclencheur.

Après avoir utilisé notre application sur le terrain pendant environ un an, utilisée par des centaines de clients chaque jour, la seule chose que je changerais si nous partions de zéro serait de concevoir notre système pour la création de fonctions de base de données (ou de procédures stockées). , comme vous voulez les appeler) avec le contrôle de version et les mises à jour à l’esprit dès le départ.

Heureusement, nous avons un système en place pour garder une trace des versions de schéma, nous avons donc construit quelque chose de plus pour prendre en charge le remplacement des fonctions de base de données. & nbsp; Cela nous aurait permis de gagner un peu de temps maintenant si nous avions envisagé de les remplacer dès le début.

Bien entendu, tout change lorsque vous sortez du domaine des SGBDR pour vous rendre dans des systèmes de stockage à tuples comme Amazon SimpleDB et BigTable de Google. & nbsp; Mais c’est une autre histoire:)

Nous utilisons beaucoup de logique métier dans les procédures stockées. Ce n'est pas idéal, mais c'est souvent un bon équilibre entre performances et fiabilité.

Et nous savons où il se trouve sans avoir à chercher parmi des centaines de solutions et de bases de code!

L’évolutivité est également un facteur très important pour appliquer la logique d’entreprise au niveau de la couche intermédiaire ou de la couche application à la couche de base de données.

Je me souviens d'avoir lu un article quelque part qui indiquait que pratiquement tout peut faire partie, à un certain niveau, de la logique commerciale, et la question n'a donc aucun sens.

Je pense que l'exemple donné était l'affichage d'une facture à l'écran. La décision de marquer un retard en rouge est une décision commerciale ...

C'est un continuum. IMHO le facteur le plus important est la vitesse. Comment faire en sorte que cette ventouse soit opérationnelle le plus rapidement possible tout en adhérant à de bons tenants en programmation, tels que la maintenabilité, les performances, l’évolutivité, la sécurité, la fiabilité, etc. le plus performant à plusieurs reprises, sauf pour les opérations sur les chaînes, etc. Ma conviction est de répandre généreusement la logique métier partout où vous le jugez préférable. Si vous avez un groupe de développeurs d’applications qui chient en regardant SQL, laissez-les utiliser leur logique applicative. Si vous voulez vraiment créer une application hautes performances avec de grands ensembles de données, insérez autant de logique que possible dans la base de données. Lancez vos administrateurs de base de données et donnez aux développeurs la liberté ultime sur leurs bases de données Dev Il n’existe pas de solution unique ni d’outil idéal pour le poste. Vous disposez de plusieurs outils, devenez un expert à tous les niveaux de l'application et vous constaterez rapidement que vous passez beaucoup plus de temps à écrire un code SQL concis et expressif, le cas échéant, et à utiliser la couche d'application à d'autres moments. Pour moi, finalement, réduire le nombre de lignes de code est ce qui mène à la simplicité. Nous venons de convertir une application riche en SQL avec seulement 2 500 lignes de code d'application et 1 000 lignes de SQL en un modèle de domaine qui compte maintenant 1 500 lignes de code d'application et 2 500 lignes de SQL pour atteindre les objectifs de l'ancienne application riche en SQL. Si vous pouvez justifier une multiplication par 6 du code sous la forme "" simplifié " puis allez-y.

C'est une excellente question! J'ai trouvé cela après avoir déjà posé la même question à un question , mais ceci est plus spécifique. Cela découle d'une décision de modification de la conception à laquelle je n'ai pas participé.

En gros, on m'avait dit que si vous aviez des millions de lignes de données dans vos tables de base de données, envisagez de placer la logique métier dans les procédures stockées et les déclencheurs. C’est ce que nous faisons actuellement: convertir une application java en procédures stockées pour en faciliter la maintenance, le code java étant devenu compliqué.

J'ai trouvé cet article dans: The Business Logic Wars L'auteur a également créé le million de lignes dans un argument de table, ce que j'ai trouvé intéressant. Il a également ajouté la logique métier en javascript, côté client et en dehors du niveau logique. Je n'y avais pas pensé auparavant, même si j'avais utilisé javascript pour la validation pendant des années, parallèlement à la validation côté serveur.

Mon avis est que vous voulez la logique métier dans le niveau application / intermédiaire comme règle générale, mais ne négligez pas les cas dans lesquels il est judicieux de l'insérer dans la base de données.

Un dernier point, je travaille actuellement sur un autre groupe qui effectue un travail de base de données considérable pour la recherche et dont la quantité de données est énorme. Cependant, pour eux, ils n’ont pas de logique métier dans la base de données elle-même, mais la conservent dans le niveau application / intermédiaire. Pour leur conception, le niveau applicatif / intermédiaire était le bon endroit pour cela. Par conséquent, je n’utiliserais pas la taille des tables comme seul élément à prendre en compte dans la conception.

La logique métier est généralement incarnée par des objets et par les diverses constructions de langage d'encapsulation, d'héritage et de polymorphisme. Par exemple, si une application bancaire transfère de l’argent, il peut exister un type d’argent qui définit les éléments commerciaux de ce que "argent". est. Ceci, opposé à l’utilisation d’un nombre décimal primitif pour représenter l’argent. Pour cette raison, la POO bien conçue correspond à la "logique métier". vies - pas strictement dans aucune couche.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow