Nous concevons un langage de programmation multi-paradigme. Partie 2 - Comparaison de la construction de modèles en PL / SQL, LINQ et GraphQL

Dans le dernier messageJ'ai posé la question que la logique métier des systèmes d'information modernes comporte de nombreux éléments dont les descriptions sont de nature déclarative: la structure des concepts, les relations entre eux, les conditions, les règles, la transformation des concepts lors du passage d'une couche de l'application à une autre, leur union, filtrage, agrégation, etc. De mon point de vue, les styles fonctionnels et orientés objet sont inférieurs au logiques en termes de commodité de mise en œuvre logicielle du modèle de domaine. Le style logique transmet les relations entre les concepts d'une manière plus compacte et naturelle. Par conséquent, je me suis fixé pour objectif de créer un langage de programmation hybride qui combinerait un paradigme orienté objet ou fonctionnel avec un paradigme logique. De plus, le composant logique devrait être pratique pour décrire le modèle de domaine - la structure de ses concepts,ainsi que les relations et les dépendances entre eux.



Dans cet article, je veux parler de certains langages et technologies populaires qui incluent des éléments de programmation déclarative - PL / SQL , MS LINQ et GraphQL . J'essaierai de comprendre quelles tâches y sont résolues à l'aide de la programmation déclarative, à quel point les approches déclarative et impérative sont étroitement liées, quels avantages cela donne et quelles idées peuvent en être tirées.

Extensions procédurales SQL

Commençons par un domaine dans lequel cette association est depuis longtemps devenue un standard de l'industrie: les langages d'accès aux données. Le plus célèbre d'entre eux est PL / SQL, une extension procédurale du langage SQL. Ce langage vous permet de traiter des données dans une base de données relationnelle en utilisant à la fois des styles de programmation impératifs (variables, instructions de contrôle, fonctions, objets) et déclaratifs (expressions SQL). À l'aide d'une requête SQL, nous pouvons décrire les propriétés des données dont nous avons besoin - quels champs sont nécessaires, à partir de quelles tables les extraire, comment elles sont liées les unes aux autres, à quelles contraintes elles doivent se conformer, comment elles doivent être agrégées, etc. Et le serveur de base de données établira indépendamment un plan d'exécution des requêtes et trouvera tous les ensembles possibles de champs qui remplissent les conditions spécifiées. La partie procédurale de PL / SQL vous permet de mettre en œuvre ces tâchesqui sont difficiles ou impossibles à exprimer sous une forme déclarative - pour traiter le résultat d'une requête dans une boucle, effectuer des calculs arbitraires, structurer le code en fonctions et en classes.



Les composants procéduraux et déclaratifs du langage sont étroitement intégrés. PL / SQL vous permet de déclarer des fonctions, d'exécuter des requêtes à l'intérieur et de renvoyer leurs résultats, d'utiliser des fonctions à l'intérieur d'une requête, en leur transmettant les valeurs des champs de la table comme arguments. Vous pouvez accéder aux résultats d'une requête à l'aide de curseurs puis boucler impérativement tous les enregistrements reçus. Les curseurs vous donnent plus de contrôle sur le contenu des tables et vous permettent d'implémenter une logique de traitement de données beaucoup plus complexe que d'utiliser SQL seul. Un curseur peut être affecté à une variable de curseur et passé en argument à des fonctions, des procédures ou même une application cliente. Le code de requête lui-même peut être généré dynamiquement par une séquence de commandes impératives.La combinaison de procédures et de requêtes, à l'aide de quelques ajustements, vous permet d'implémenter des requêtes récursives. Il existe même des fonctionnalités orientées objet dans PL / SQL qui vous permettent de déclarer des types de données composites pour les champs de table, d'y inclure des méthodes et de créer des classes par héritage.



PL / SQL vous permet d'implémenter la logique métier côté serveur de base de données. De plus, l'implémentation du modèle de domaine sera assez proche de sa description. Les concepts de base du modèle de domaine seront mappés sur le modèle de données relationnelles. Les concepts correspondront aux tables, aux attributs - à leurs champs. Les contraintes sur les valeurs de champ peuvent être intégrées dans les descriptions de table. Et les relations avec d'autres tables peuvent être définies à l'aide de clés étrangères. Les concepts abstraits construits sur la base des concepts de base correspondront à la vue. Ils peuvent être utilisés dans des requêtes avec des tables, y compris pour créer d'autres vues. Les vues sont construites sur la base de requêtes, ce qui vous permet d'utiliser toute la puissance et la flexibilité de SQL. De cette façon,à partir de tables et de vues, vous pouvez créer un modèle de domaine assez complexe et à plusieurs niveaux complètement dans un style déclaratif. Et tout ce qui ne rentre pas bien dans le style déclaratif peut être implémenté à l'aide de procédures et de fonctions.



Le principal problème est que le code PL / SQL est exécuté exclusivement côté serveur de base de données. Cela rend difficile la mise à l'échelle d'une telle solution. De plus, le modèle résultant sera lié de manière rigide à la base de données relationnelle et il sera problématique d'y inclure des données provenant d'autres sources.

Requête intégrée au langage

La requête intégrée au langage (LINQ) est un composant populaire de la plate-forme .NET qui vous permet d'inclure naturellement des expressions de requête SQL dans votre code de langage orienté objet principal. Contrairement à PL / SQL, qui ajoute un paradigme impératif à SQL côté serveur de base de données, LINQ amène SQL au niveau de l'application. Grâce à cela, les requêtes dans LINQ peuvent être utilisées pour obtenir des données non seulement à partir de bases de données relationnelles, mais également à partir de collections d'objets, de documents XML et d'autres requêtes LINQ.



L'architecture LINQ est assez flexible et les définitions de requête sont profondément intégrées au modèle POO. LINQ vous permet de créer vos propres fournisseurs pour accéder à de nouvelles sources de données. Vous pouvez également définir votre propre façon d'exécuter la requête et, par exemple, convertir l'arborescence d'expression LINQ de la requête en requête vers la source de données souhaitée. Vous pouvez utiliser des expressions et fonctions lambda définies dans le code de votre application dans le corps de votre requête. Certes, dans le cas de LINQ to SQL, la requête sera exécutée côté serveur de base de données, où ces fonctions ne seront pas disponibles, mais des procédures stockées peuvent être utilisées à la place. La requête est l'essence même du langage de premier niveau, vous pouvez travailler avec elle comme avec un objet ordinaire. Le compilateur est capable de déduire automatiquement le type du résultat de la requête et de générer la classe appropriée, même si elle n'a pas été explicitement déclarée.



Essayons d'utiliser LINQ pour créer un modèle de domaine sous la forme d'un ensemble de requêtes. Les faits initiaux peuvent être placés dans des listes côté application ou dans des tables côté base de données, et les concepts abstraits peuvent être formatés sous forme de requêtes LINQ. LINQ vous permet de créer des requêtes basées sur d'autres requêtes en les spécifiant dans la clause FROM. Cela vous permet de construire un nouveau concept basé sur des concepts existants. Les champs de la section SELECT correspondront aux attributs du concept. Et la section WHERE contiendra les dépendances entre les concepts. Un exemple avec des factures d'une publication précédente ressemblera à ceci.



Nous placerons des objets avec des comptes et des informations client dans les listes:

List<Bill> bills = new List<Bill>() { ... };
List<Client> clients = new List<Client>() { ... };

Et puis créons des requêtes pour qu'ils obtiennent des factures impayées et des débiteurs:

IEnumerable<Bill> unpaidBillsQuery =
from bill in bills
where bill.AmountToPay > bill.AmountPaid 
select bill;
IEnumerable<Client> debtorsQuery =
from bill in unpaidBillsQuery 
join client in clients on bill.ClientId equals client.ClientId
select client;

Le modèle de domaine implémenté à l'aide de LINQ a pris une forme plutôt bizarre - plusieurs styles de programmation sont impliqués à la fois. Le niveau supérieur du modèle a une sémantique impérative. Il peut être représenté comme des chaînes de transformations d'objets, créant des collections d'objets au-dessus des collections. Les objets de requête sont des éléments du monde POO. Ils doivent être créés, affectés à des variables et les références à celles-ci doivent être transmises à d'autres requêtes. Au niveau intermédiaire, l'objet de requête implémente la procédure d'exécution d'une requête, qui est fonctionnellement personnalisée avec des expressions lambda qui vous permettent de former la structure de résultat dans la section SELECT et de filtrer les enregistrements dans la clause WHERE. Le niveau interne est représenté par une procédure d'exécution de requête qui a une sémantique logique et est basée sur l'algèbre relationnelle.



Bien que LINQ ait permis de décrire le modèle de domaine, la syntaxe SQL vise principalement à récupérer et à manipuler des données. Il manque quelques constructions qui seraient utiles dans la modélisation. Si en PL / SQL la structure des concepts de base était très clairement représentée sous forme de tables et de vues, alors dans LINQ, elle s'est avérée être rendue en code POO. En outre, alors que les tables et les vues peuvent être référencées par leur nom, les requêtes LINQ peuvent être référencées dans un style impératif. De plus, SQL est limité par le modèle relationnel et a des capacités limitées lors de l'utilisation de structures sous forme de graphes ou d'arbres.

Parallèles entre le modèle relationnel et la programmation logique

Vous pouvez voir que les implémentations SQL et Prolog du modèle présentent des similitudes. En SQL, nous construisons une vue basée sur des tables ou d'autres vues, et dans Prolog, nous construisons des règles basées sur des faits et des règles. En SQL, les tables sont une collection de champs et les prédicats dans Prolog sont une collection d'attributs. En SQL, nous spécifions les dépendances entre les champs de table sous forme d'expressions dans la clause WHERE et dans Prolog, en utilisant des prédicats et des variables booléennes qui lient les attributs de prédicat les uns aux autres. Dans les deux cas, nous définissons de manière déclarative la spécification de la solution, et le moteur d'exécution de requête intégré nous renvoie les enregistrements trouvés dans SQL ou les valeurs possibles des variables dans Prolog.



Cette similitude n'est pas accidentelle. Bien que le fondement théorique de SQL - algèbre relationnelle ait été développé en parallèle avec la programmation logique, mais plus tard, un lien théorique a été révélé entre eux. Ils ont une base mathématique commune - la logique du premier ordre. Le modèle de données relationnel décrit les règles de création de relations entre les tables de données, la programmation logique - entre les instructions. Les deux théories utilisent des termes différents, sont appliquées dans des domaines différents, ont été développées en parallèle, mais elles avaient une base mathématique commune.



À proprement parler, le calcul relationnel est une adaptation de la logique du premier ordre pour travailler avec des données tabulaires. Cette question est discutée plus en détail ici.... Autrement dit, toute expression d'algèbre relationnelle (toute requête SQL) peut être reformulée en une expression de logique du premier ordre, puis implémentée dans Prolog. Mais pas l'inverse. Le calcul relationnel est un sous-ensemble de la logique du premier ordre. Cela signifie que pour certains types d'énoncés admissibles en logique du premier ordre, nous ne pouvons pas trouver d'analogies en algèbre relationnelle. Par exemple, les capacités des requêtes récursives en SQL sont très limitées et la construction de relations transitives n'est pas toujours disponible. Les opérations Prolog telles que la disjonction de cible et la négation comme le refus sont beaucoup plus difficiles à implémenter en SQL. La syntaxe flexible de Prolog vous offre plus de flexibilité pour travailler avec des structures imbriquées complexes et prend en charge les opérations de correspondance de modèles sur celles-ci.Cela le rend pratique lorsque vous travaillez avec des structures de données complexes telles que des arbres et des graphiques.



Mais il faut tout payer. Les algorithmes d'exécution de requêtes intégrés dans les bases de données relationnelles sont plus simples et moins polyvalents que les algorithmes d'inférence de Prolog. Cela permet de les optimiser et d'atteindre des performances bien supérieures. Prolog est également incapable de traiter rapidement des millions de lignes dans des bases de données relationnelles. De plus, l'algorithme d'inférence de Prolog ne garantit pas du tout la fin de l'exécution du programme - la sortie de certaines instructions peut conduire à une récursion infinie.



À propos, à l'intersection des bases de données et de la programmation logique, il existe également des technologies telles que les bases de données déductives et le langage des règles et des requêtes pour eux Datalog. Au lieu d'enregistrements dans des tables, les bases de données déductives stockent de grandes quantités de faits et de règles dans un style logique. Et Datalog ressemble à Prolog, mais il se concentre sur le travail avec des faits combinés dans des ensembles, pas des faits uniques. De plus, certaines fonctionnalités de la logique du premier ordre ont été supprimées afin d'optimiser l'algorithme d'inférence pour un travail rapide avec de grandes quantités de données. La syntaxe moins expressive d'un langage logique a donc aussi ses avantages.

Approche déclarative de la description de la couche API

SQL lie la construction du modèle à la couche d'accès aux données. Mais la programmation déclarative se développe activement à l'extrémité opposée de l'application - dans la couche API. Sa particularité est que les informations sur la structure des requêtes doivent être disponibles pour ceux qui utilisent cette API. Avoir une description formelle de la structure des demandes et des réponses est une bonne forme. En conséquence, il existe un désir de synchroniser cette description avec le code d'application, par exemple, générer des classes de demande et de réponse sur la base de celui-ci. Dans lequel vous devrez ensuite écrire la logique de traitement des requêtes.



GraphQL est un framework de création d'API qui va bien au-delà de cette approche traditionnelle et offre non seulement un langage de requête, mais également un environnement d'exécution de requête. Il n'est pas nécessaire de générer du code, le moteur d'exécution comprend de toute façon les descriptions des requêtes. Pour implémenter l'API à l'aide de GraphQL, vous avez besoin:

1. décrire les types de données (objets) de l'application qui font partie des demandes et des réponses;
2. décrire la structure des demandes et des réponses;
3. implémenter des fonctions qui implémentent la logique de création d'objets pour obtenir les valeurs de leurs champs.

Les types de données sont des descriptions de champs d'objet. Les types tels que les types scalaires, les listes, les énumérations et les références aux types imbriqués sont pris en charge. Étant donné que les champs de type peuvent contenir des références à d'autres types, l'ensemble du schéma de données peut être représenté sous forme de graphique. La demande est une description de la structure de données demandée à l'API. La description de la demande comprend une liste des objets requis, leurs champs et les attributs d'entrée. Chaque type de données et chacun de ses champs doivent être associés à une fonction de résolution. Le résolveur de type (objet) décrit l'algorithme pour obtenir ses objets, le résolveur de champ décrit les valeurs du champ objet. Ils représentent des fonctions dans l'un des langages fonctionnels ou orientés objet. Le runtime GraphQL reçoit une requête, détermine les types de données requis, appelle leurs résolveurs, y compris le long d'une chaîne d'objets imbriqués,recueille un objet de réponse.



GraphQL combine la description de schéma de données déclarative avec des algorithmes impératifs ou fonctionnels pour les obtenir. Le schéma de données est décrit explicitement et est au cœur de l'application. De nombreuses personnes soulignent qu'il est recommandé de créer un schéma de données qui ne duplique pas les schémas de source de données, mais qui soit conforme au modèle de domaine. Cela fait de GraphQL une solution très populaire pour l'intégration de sources de données disparates.



Ainsi, le langage GraphQL permet d'exprimer le modèle de domaine de manière assez claire, de le distinguer du reste du code, de rapprocher le modèle et son implémentation. Malheureusement, le composant déclaratif du langage se limite uniquement à la description de la composition des types de données; toutes les autres relations entre les éléments du modèle doivent être implémentées à l'aide de résolveurs. D'une part, les résolveurs permettent à un développeur de mettre en œuvre indépendamment toute méthode d'obtention de données pour un objet et toute relation entre eux. Mais, d'un autre côté, vous devrez essayer d'implémenter des options de requête plus complexes que, par exemple, l'accès à un enregistrement par clé. D'une part, le schéma de données dans GraphQL montre clairement la relation entre la couche API et la couche d'accès aux données. Mais, d'un autre côté, la couche principale à laquelle le schéma de données est lié est la couche API.Le contenu du schéma de données s'y ajuste; il ne contiendra pas d'entités qui ne sont pas impliquées dans le traitement des demandes. Bien que la puissance expressive du langage de description de données GraphQL soit inférieure à des langages déclaratifs à part entière comme SQL et Prolog, la popularité de ce framework montre que les outils de description déclarative du modèle peuvent et doivent faire partie des langages de programmation modernes.

Je vais résumer

PL / SQL est un langage pratique à la fois pour décrire un modèle de domaine sous forme de tables et de vues, et pour la logique de son utilisation. Les composantes déclarative et procédurale sont étroitement intégrées et complémentaires. Le principal problème est que ce langage est étroitement lié à l'emplacement de stockage des données, il ne peut être exécuté que du côté serveur de base de données et la logique d'exécution de la requête est limitée au modèle de données relationnel.



Côté application, vous pouvez utiliser des technologies telles que LINQ et GraphQL pour décrire le modèle sous une forme déclarative. En utilisant le schéma de données GraphQL, vous pouvez décrire clairement et très clairement la structure du modèle de domaine, l'imbrication de ses concepts. Et le runtime est capable de collecter automatiquement les objets requis. Malheureusement, toutes les autres relations et connexions entre les concepts, à l'exception de leur imbrication, doivent être implémentées dans la couche des fonctions de résolution. LINQ a des avantages et des inconvénients opposés. La syntaxe SQL flexible vous donne plus de flexibilité pour décrire les relations entre les concepts. Mais en dehors de la requête, la déclarativité prend fin, les objets de requête sont des éléments du monde OOP. Ils doivent être créés, affectés à des variables et utilisés dans un style impératif.



Je voudrais combiner les avantages de LINQ et GraphQL. Pour que la description de la structure des concepts soit claire comme dans GraphQL, et que les relations entre eux puissent être définies en fonction de la logique comme en SQL. Et pour que les définitions de concepts soient disponibles directement par nom en tant que classes, sans qu'il soit nécessaire de créer explicitement leurs objets, de les affecter à des variables, de leur passer des références, etc.



Je vais commencer à concevoir une telle solution en développant un langage pour décrire un modèle de domaine. Mais pour cela, il est nécessaire de faire un tour d'horizon des langages existants de représentation des connaissances. Par conséquent, dans la prochaine publication, je veux parler de programmation logique, RDF, OWL et langages de logique de trame, les comparer et essayer de trouver de telles fonctionnalités qui seraient intéressantes pour le langage conçu pour décrire la logique métier.



Pour ceux qui ne veulent pas attendre la sortie de toutes les publications sur Habré, il existe un texte intégral de style scientifique en anglais, disponible sur le lien: Programmation orientée ontologie hybride pour le traitement de données semi-structurées .



Liens vers les publications précédentes:

Conception d'un langage de programmation multi-paradigme. Partie 1 - À quoi ça sert?