L'âge de la logique de domaine dans les bases de données est-il dépassé? [fermé]

J'ai récemment trébuché sur cette opinion de 2016 en disant qu'il y avait toujours des arguments en faveur de la logique du domaine dans la base de données.

Je pensais que c'était totalement obsolète. Je me demande simplement si le gars vit encore dans les années 90 ou si cela peut être vraiment vrai. Mettez de côté les anciens systèmes.

Qu'en est-il de la logique du domaine dans la base de données en raison des exigences de sécurité? Est-ce vraiment une chose à faire?

database

— ps-aux
source

Avez-vous réellement lu cet article dans son intégralité? Je pense que l'auteur explique très bien son point de vue et explique pour quelles parties du BL il pense être le mieux placé dans une base de données, et pour quelles parties il ne l'est pas. Alors, avec quels points de cet article exactement vous vous débattez?

— Doc Brown

Oui, il a fermé le 18 février 2009 et est désormais faux.

— Michael Durrant

C'est curieux. J'ai lu ce gars, donnant beaucoup d'exemples SQL (fortement liés à Oracle) et puis je ne peux pas m'empêcher de me rappeler que mon client m'a dit: j'ai oublié d'acheter la licence d'Oracle pour l'env PRE. Nous l'avons pour PRO mais pas pour PRE. Vous devrez déployer l'application, contre MySQL dans PRE et Oracle dans PRO, pendant un petit moment ... Je demanderai à ce type où toutes les fonctionnalités brillantes d'Oracle vont maintenant ... (Le problème ici était que pour une raison Je ne veux pas savoir, l'architecte a décidé de passer au mode natif de mappage des lignes SQL au lieu d'Orm, mais toujours proche du problème d'être verrouillé sur le fournisseur de base de données) .

— Laiv

@Laiv: C'est fou, et aucune quantité d'ORM ou d'autres abstractions ne vous sauvera. Vous déployez essentiellement du code non testé en production avec une telle configuration.

— JacquesB

"L'âge de la logique de domaine dans les bases de données est-il révolu?" Dieu, je l'espère.

— lunchmeat317

Réponses:

De nos jours, les programmeurs semblent penser de manière très dogmatique, surtout lorsqu'ils lisent les pensées que d'autres personnes écrivent dans leurs blogs.

Prenez le blog Clean Coding de Bob Martin, par exemple. Comme observation générale, je trouve les écrits de Bob Martin assez clairs et lucides, donc cela me déconcerte que les gens soient constamment confus par les choses qu'il écrit, comme les principes SOLID. Ils se demandent ce qu'une «responsabilité unique» devrait être, ou pourquoi une classe viole les principes de Liskov, alors que ce qu'ils devraient probablement faire est simplement de s'efforcer d'écrire un meilleur code et d'acquérir d'abord de l'expérience, afin que ce qu'ils lisent dans les blogs ont un certain contexte.

Fondamentalement, ce que vous dites, c'est que la base de données devrait contenir des tables et des données, et c'est tout ce qu'elle devrait contenir. Mais les bases de données sont particulièrement adaptées pour faire certaines choses pour lesquelles ... eh bien, les bases de données sont bonnes.

L'article cite ces choses:

Intégrité et validation des données (par exemple, contraintes nulles et uniques)
Sécurité au niveau des lignes
Écriture d'une API à l'aide de procédures stockées
Calcul des soldes
Poser les questions de la base de données (c.-à-d. Interrogation et rapport)
Éviter les problèmes ORM tels que N + 1

comme des choses appropriées pour mettre dans la base de données. Je suis d'accord avec lui.

Raisons pour lesquelles vous ne mettez pas la logique métier (en général) dans une base de données:

Verrouillage fournisseur
Votre base de données n'est pas l'autorité centrale
Votre équipe ne pense pas relationnellement
Outillage inférieur.

Mais ces choses ne s'appliquent généralement qu'aux techniques, outils et formations pour lesquels la base de données n'est pas particulièrement adaptée.

Ainsi, comme pour toute autre technique de développement logiciel, cela dépend. Vous évaluez vos alternatives et prenez votre décision en fonction de ce que vous pensez être le meilleur plan d'action possible pour votre application spécifique.

— Robert Harvey
source

Une très bonne ventilation et une meilleure façon de formuler la question.

— candied_orange

L'âge du cheval et du buggy est révolu, mais vous pouvez toujours acheter des fouets pour buggy.

Pourquoi? Lorsque les voitures sont plus rapides, moins chères à entretenir et que les négliger ne produira pas de visites de la société humaine, pourquoi le cheval et la charrette sont-ils toujours là?

Parce que parfois, vous avez des raisons différentes de faire quelque chose en plus des raisons populaires.

Ce que vous devez apprendre, c'est pourquoi la logique du domaine dans une base de données cause des problèmes et ce que n'importe qui pourrait en retirer. Décidez-vous ensuite.

Ma vision personnelle:

La logique du domaine concerne le comportement. Les bases de données concernent la persistance, les relations et, enfin, les données. Lorsque vous le voyez de cette façon, les règles métier ne doivent pas figurer dans la base de données.

D'un autre côté, qui a déclaré que la base de données ne pouvait pas avoir de comportement? J'ai construit des bases de données de bureau en utilisant Filemaker. Les gens l'appellent une base de données, mais c'est vraiment tout un environnement de développement d'applications. Tout est parfaitement intégré en un, et appelé une base de données.

Wizdom se trouve généralement entre des vues extrêmes. Je n'ai aucun doute non plus. En essayant de trouver le milieu, il est tentant de simplement suivre le troupeau. Je mettrai en garde contre cela ici.

Un système qui conserve la logique du domaine dans la base de données peut bien fonctionner. Un système qui garde la logique du domaine hors de la base de données peut bien fonctionner. Un système qui mélange la logique du domaine aux deux endroits va me rendre fou. Je ne saurai pas où mettre de nouveaux comportements. Je ne sais pas où trouver l'ancien comportement.

Si vous ne pouvez toujours pas décider de lancer une pièce et de prendre sa décision comme un évangile pour un projet particulier. Autant que je sache, cette pièce sait ce qui est le mieux aussi bien que n'importe qui d'autre.

— candied_orange
source

Votre réponse semble que vous n'avez même pas jeté un coup d'œil à l'article lié par le PO (pas que je dis que l'auteur a raison ou tort), mais pouvez-vous nous dire où vous êtes d'accord ou en désaccord avec les vues décrites dans cet article?

— Doc Brown

@DocBrown Je ne l'ai pas lu non plus, mais cette réponse est bonne quand même, je suis entièrement d'accord. Et il aborde la OP question (dernière phrase), pas un article cité.

— qwerty_so

@DocBrown Je ne pense pas que l'article ait lu l'article d' oncle Bob qu'il cite : "Les architectures de plug-in sont très robustes parce que les règles commerciales stables de haute valeur peuvent être empêchées de dépendre de modules volatils de faible valeur tels que les interfaces utilisateur et les bases de données.". L'oncle Bob est plus opposé que moi à cette idée. Cet article choisit l'article de Bob et donne l'impression que Bob dit quelque chose qu'il n'est pas.

— candied_orange

J'ai eu un cas où le résoudre dans la couche métier aurait été un véritable tueur de performances.

Notre concept de sécurité OO d'application se compose de rôles ET de groupes. Et les deux sont des structures récursives. Nous avons écrit une procédure stockée qui résout l'autorisation pour un utilisateur sur un objet de domaine.

Il y a vraiment moins de besoin de revenir à la logique de la base de données. Mais dans ce cas, j'ai décidé de suivre cette voie. Mais ce que vous devez toujours considérer: vous abandonnez l'abstraction. Dès que vous avez une logique métier dans la base de données, vous avez du mal à changer votre couche de persistance. Soyez donc très très prudent.

— oopexpert
source