La vérité d'abord, ou pourquoi le système doit être conçu en fonction de la base de données

Salut, Habr !

Nous continuons à explorer le sujet Java et Printemps, y compris au niveau des bases de données. Aujourd'hui, nous vous proposons de lire pourquoi, lors de la conception de grandes applications, la structure de la base de données, et non le code Java, devrait avoir une importance primordiale, comment cela se fait, et quelles sont les exceptions à cette règle.

Dans cet article quelque peu tardif, j'expliquerai pourquoi je crois que dans presque tous les cas, le modèle de données dans une application doit être conçu « en fonction de la base de données », et non « en fonction des capacités de Java » (ou d'un autre langage client avec lequel vous travaillez). En choisissant la deuxième approche, vous vous engagez sur un long chemin de douleur et de souffrance dès que votre projet commence à croître.

Cet article est inspiré par une question, posée sur Stack Overflow.

Des discussions intéressantes sur reddit dans les sections /r/java et /r/programming.

Génération de code

Je suis tellement surpris qu'il existe une si petite couche d'utilisateurs qui, après avoir rencontré jOOQ, s'offusquent du fait qu'avec jOOQ, on s'appuie sérieusement sur la génération de code. Personne ne vous empêche d'utiliser jOOQ comme vous le souhaitez et ne vous force à utiliser la génération de code. Mais par défaut (comme décrit dans le manuel), travailler avec jOOQ se déroule ainsi : vous partez d'un schéma de base de données (hérité), vous effectuez une rétro-conception à l'aide du générateur de code jOOQ pour obtenir un ensemble de classes représentant vos tables, puis vous écrivez des requêtes type-safes à ces tables :

	for (Record2 record : DSL.using(configuration)
//   ^^^^^^^^^^^^^^^^^^^^^^^ Informations sur les types déduites de 
//   code généré auquel se réfère la condition SELECT ci-dessous

       .select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
//           vvvvv ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^ noms générés
       .from(ACTOR)
       .orderBy(1, 2)) {
    // ...
}

Le code est généré soit manuellement en dehors de la construction, soit manuellement à chaque construction. Par exemple, une telle régénération peut se produire juste après la migration de la base de données Flyway, qui peut également être effectuée manuellement ou automatiquement.

Génération de code source

Avec ces approches de génération de code - manuelles et automatiques - sont associées différentes philosophies, avantages et inconvénients, que je ne vais pas détailler dans cet article. Mais, en général, toute l'essence du code généré réside dans le fait qu'il permet de reproduire en Java cette "vérité" que nous considérons comme acquise, soit dans le cadre de notre système, soit en dehors de celui-ci. D'une certaine manière, c'est ce que font les compilateurs, générant du bytecode, du code machine ou tout autre type de code à partir des sources - nous obtenons une représentation de notre "vérité" dans un autre langage, indépendamment des raisons spécifiques.

Il existe de nombreux générateurs de code. Par exemple, XJC peut générer du code Java à partir de fichiers XSD ou WSDL.Le principe est toujours le même :

• Il existe une certaine vérité (interne ou externe) - par exemple, une spécification, un modèle de données, etc.
• Nous avons besoin d'une représentation locale de cette vérité dans notre langage de programmation.

Il est presque toujours judicieux de générer une telle représentation - pour éviter la redondance.

Providers de types et traitement des annotations

À noter : une autre approche, plus moderne et spécifique, de génération de code pour jOOQ implique l'utilisation de providers de types, tels qu'ils sont réalisés en F#.Dans ce cas, le code est généré par le compilateur, précisément au stade de la compilation. Sous forme de sources, ce code n'existe fondamentalement pas. En Java, il existe des outils similaires, bien que moins élégants - ce sont les processeurs d'annotations, par exemple, Lombok..

Dans un certain sens, les mêmes choses se produisent ici que dans le premier cas, à l'exception de :

• Vous ne voyez pas le code généré (peut-être que cette situation ne semble pas si repoussante à quelqu'un ?)
• Vous devez garantir que les types peuvent être fournis, c'est-à-dire que la "vérité" doit toujours être accessible. Cela est facile dans le cas de Lombok, qui annotent la "vérité". Cela devient un peu plus compliqué avec des modèles de bases de données, dont le fonctionnement dépend d'une connexion active constamment disponible.

Quel est le problème avec la génération de code ?

En plus de la question délicate de savoir comment il est préférable de lancer la génération de code – manuellement ou automatiquement, il convient également de mentionner qu'il y a des personnes qui pensent que la génération de code n'est tout simplement pas nécessaire. Le raisonnement derrière ce point de vue, que j'ai rencontré le plus souvent, est que cela rend difficile la configuration du pipeline de construction. Oui, c'est effectivement compliqué. Cela entraîne des coûts d'infrastructure supplémentaires. Si vous débutez avec un produit particulier (qu'il s'agisse de jOOQ, JAXB, Hibernate, etc.), le temps consacré à la configuration de l'environnement de travail est du temps que vous préféreriez passer à étudier l'API elle-même afin d'en tirer de la valeur par la suite.

Si les coûts liés à la compréhension du fonctionnement du générateur sont trop élevés, alors effectivement, cela signifie que l'API n'a pas suffisamment travaillé sur l'ergonomie du générateur de code (et il s'avère par la suite que la personnalisation utilisateur y est également complexe). La facilité d'utilisation doit être la priorité absolue pour toute API de ce type. Mais c'est juste un argument contre la génération de code. Par ailleurs, il est totalement possible d'écrire manuellement la représentation locale de la vérité interne ou externe.

Beaucoup diront qu'ils n'ont pas le temps de s'occuper de tout cela. Ils ont des délais serrés pour leur Super Produit. On s'occupera des pipelines de construction plus tard, il y aura le temps. Je leur réponds :

Original, Alan O'Rourke, Audience Stack

Mais avec Hibernate / JPA, il est si facile d'écrire du code « sous Java ».

Effectivement. Pour Hibernate et ses utilisateurs, c'est à la fois une bénédiction et une malédiction. Avec Hibernate, on peut simplement écrire quelques entités comme ceci :

	@Entity
class Book {
  @Id
  int id;
  String title;
}

Et presque tout est prêt. Maintenant, la tâche d'Hibernate est de générer les détails complexes de la manière dont cette entité sera définie dans le DDL de votre dialecte SQL :

	CREATE TABLE book (
  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  title VARCHAR(50),

  CONSTRAINT pk_book PRIMARY KEY (id)
);

CREATE INDEX i_book_title ON book (title);

… et nous commençons à faire fonctionner l'application. C'est vraiment une fonctionnalité incroyable pour commencer rapidement à travailler et à essayer différentes choses.

Cependant, permettez-moi. J'ai exagéré.

• Est-ce qu'Hibernate appliquera vraiment la définition de cette clé primaire nommée ?
• Est-ce qu'Hibernate va créer un index dans TITLE ? – je sais pertinemment qu'il nous sera nécessaire.
• Est-ce qu'Hibernate fera vraiment de cette clé une clé identifiant dans la spécification d'identité ?

Probablement pas. Si vous développez votre projet à partir de zéro, il est toujours pratique de simplement abandonner l'ancienne base de données et de générer une nouvelle dès que vous ajoutez les annotations nécessaires. Ainsi, l'entité Book finira par avoir la forme suivante :

	@Entity
@Table(name = "book", indexes = {
  @Index(name = "i_book_title", columnList = "title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
  String title;
}

Génial. Générer à nouveau. Encore une fois, dans ce cas, cela sera très facile au départ.

Mais par la suite, cela aura un coût.

Tôt ou tard, il faudra passer en production. C'est à ce moment-là que ce modèle cessera de fonctionner. Parce que :

En production, vous ne pourrez plus abandonner l'ancienne base de données et tout recommencer à zéro si nécessaire. Votre base de données sera considérée comme héritée.

À partir de maintenant et pour toujours, vous devrez écrire des scripts de migration DDL, par exemple, en utilisant Flyway.. Que se passera-t-il alors avec vos entités ? Vous pourrez soit les adapter manuellement (et ainsi doubler votre volume de travail), soit demander à Hibernate de les générer à nouveau pour vous (quelles sont les chances que ce soit conforme à vos attentes ?). Dans tous les cas, vous perdez.

Ainsi, dès que vous serez en production, vous aurez besoin de patches à chaud. Et il faut déployer ceux-ci en production très rapidement. Étant donné que vous ne vous êtes pas préparé et n'avez pas organisé un flux de migration fluide pour la production, vous appliquerez tous des patchs qui ne seront pas bien faits. Ensuite, vous n'aurez pas le temps de tout faire correctement. Et vous blâmerez Hibernate, parce que quelqu'un d'autre est toujours responsable, sauf vous…

Au lieu de cela, tout aurait pu être fait complètement différemment dès le début. Par exemple, mettre des roues rondes sur le vélo.

D'abord la base de données.

La véritable "vérité" dans le schéma de votre base de données et la "souveraineté" sur celui-ci se trouvent dans la base de données elle-même. Le schéma n'est défini que dans la base de données elle-même et nulle part ailleurs, et chaque client a une copie de ce schéma, il est donc tout à fait logique d'imposer le respect du schéma et de son intégrité, en le faisant directement dans la base de données - là où les informations sont stockées.
C'est une vieille sagesse même usée. Les clés primaires et uniques - c'est bien. Les clés étrangères - c'est bien. La vérification des contraintes - c'est bien. Assertions – c'est bien.

Cependant, ce n'est pas tout. Par exemple, en utilisant Oracle, vous voudrez probablement spécifier :

• Dans quel espace de table se trouve votre table
• Quelle est sa valeur PCTFREE
• Quelle est la taille du cache dans votre séquence (derrière l'identifiant)

Il se peut que tout cela ne soit pas important dans les petites systèmes, mais il n'est pas nécessaire d'attendre de passer au domaine du « big data » — il est possible de commencer à tirer parti des optimisations de stockage des données fournies par le fournisseur beaucoup plus tôt, comme celles mentionnées ci-dessus. Aucune des ORM que j'ai pu voir (y compris jOOQ) ne donne accès à l'ensemble des options DDL que vous souhaiterez peut-être utiliser dans votre base de données. Les ORM offrent des outils qui aident à rédiger du DDL.

Mais au final, un schéma bien conçu est écrit manuellement en DDL. Tout DDL généré n'est qu'une approximation de celui-ci.

Qu'en est-il du modèle client ?

Comme mentionné précédemment, du côté client, vous aurez besoin d'une copie du schéma de votre base de données, une vue client. Il est superflu de mentionner que cette vue client doit être synchronisée avec le modèle réel. Comment y parvenir au mieux ? Avec un générateur de code.

Toutes les bases de données fournissent leurs métadonnées via SQL. Voici comment obtenir toutes les tables de votre base de données sur différents dialectes SQL :

	-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables

-- DB2
SELECT tabschema, tabname
FROM syscat.tables

-- Oracle
SELECT owner, table_name
FROM all_tables

-- SQLite
SELECT name
FROM sqlite_master

-- Teradata
SELECT databasename, tablename
FROM dbc.tables

Ces requêtes (ou similaires, selon qu'il faille aussi considérer les vues, les vues matérialisées, ou les fonctions à valeur tabulaire) sont également exécutées via l'appel DatabaseMetaData.getTables() de JDBC, ou via le module méta jOOQ.

À partir des résultats de telles requêtes, il est relativement facile de générer n'importe quelle vue client du modèle de votre base de données, peu importe la technologie que vous utilisez côté client.

• Si vous utilisez JDBC ou Spring, vous pouvez créer un ensemble de constantes de chaîne
• Si vous utilisez JPA, vous pouvez générer vous-même les entités
• Si vous utilisez jOOQ, vous pouvez générer la méta-modèle de jOOQ

Selon le volume de fonctionnalités proposé par votre API client (par exemple, jOOQ ou JPA), le méta-modèle généré peut être véritablement riche et complet. Prenons, par exemple, la possibilité de jointures implicites, introduite dans jOOQ 3.11, qui repose sur les métadonnées générées concernant les relations de clés étrangères entre vos tables.

Désormais, toute augmentation de la base de données entraînera automatiquement la mise à jour du code client. Imaginez par exemple :

ALTER TABLE book RENAME COLUMN title TO book_title;

Voudriez-vous vraiment faire ce travail deux fois ? Absolument pas. Il suffit de fixer le DDL, de le faire passer par votre pipeline de construction et d'obtenir l'entité mise à jour :

@Entity
@Table(name = "book", indexes = {

  // Y avez-vous déjà pensé ?
  @Index(name = "i_book_title", columnList = "book_title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;

  @Column("book_title")
  String bookTitle;
}

Ou bien la classe jOOQ mise à jour. La plupart des modifications DDL se reflètent également sur la sémantique et pas seulement sur la syntaxe. Il est donc pratique de consulter le code compilé pour voir quel code sera (ou pourrait être) impacté par l'augmentation de votre base de données.

La seule vérité

Qu'importe la technologie que vous utilisez, il existe toujours un modèle qui constitue la seule source de vérité pour un certain sous-système – ou, au minimum, nous devons viser cela et éviter cette confusion d'entreprise où "la vérité" est à la fois partout et nulle part. Tout pourrait être beaucoup plus simple. Si vous ne faites qu'échanger des fichiers XML avec un autre système, utilisez simplement des XSD. Regardez le méta-modèle INFORMATION_SCHEMA de jOOQ en forme XML :
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• L'XSD est bien comprise
• L'XSD marque très bien le contenu XML et permet de valider dans tous les langages clients
• L'XSD est bien versionnée et possède une rétrocompatibilité avancée
• L'XSD peut être transformée en code Java à l'aide de XJC

Le dernier point est important. Lors de la communication avec un système externe à l'aide de messages XML, nous voulons être sûrs de la validité de nos messages. Cela peut être facilement réalisé grâce à JAXB, XJC et XSD. Ce serait complètement insensé de penser qu'avec une approche de conception « Java d'abord », où nous faisons nos messages sous forme d'objets Java, nous pourrions les mapper de manière claire sur XML et les envoyer pour consommation dans un autre système. XML généré de cette manière serait de très mauvaise qualité, non documenté, et difficile à faire évoluer. Si un accord sur le niveau de service (SLA) existait pour cette interface, nous l'aurions immédiatement compromis.

Honnêtement, c'est exactement ce qui se passe constamment avec les API au format JSON, mais c'est une autre histoire, la prochaine fois je me fâcherai…

Bases de données : c'est la même chose

En travaillant avec des bases de données, vous comprenez qu'elles sont toutes fondamentalement similaires. Une base possède ses données et doit gérer le schéma. Toute modification apportée au schéma doit être mise en œuvre directement sur le DDL, afin de mettre à jour la source unique de vérité.

Lorsque la mise à jour de la source a eu lieu, tous les clients doivent également mettre à jour leurs copies du modèle. Certains clients peuvent être écrits en Java en utilisant jOOQ et Hibernate ou JDBC (ou tous en même temps). D'autres clients peuvent être écrits en Perl (je leur souhaite bonne chance), et d'autres encore en C#. Peu importe. Le modèle principal se trouve dans la base de données. Les modèles générés à l'aide de l'ORM sont généralement de mauvaise qualité, mal documentés, et difficiles à faire évoluer.

Alors ne faites pas d'erreurs. Ne faites pas d'erreurs dès le départ. Travaillez en vous basant sur la base de données. Construisez un pipeline de déploiement qui peut être automatisé. Incluez des générateurs de code pour faciliter la copie de votre modèle de base de données et le déploiement sur les clients. Et arrêtez de vous soucier des générateurs de code. Ils sont bons. Avec eux, vous serez plus productif. Il suffit de consacrer un peu de temps au début pour les configurer – et par la suite, vous bénéficierez de plusieurs années d’augmentation de productivité, qui formeront l’histoire de votre projet.

Ne me remerciez pas encore, plus tard.

Explication

Pour plus de clarté : Cet article ne préconise en aucun cas que l'ensemble du système (c'est-à-dire le domaine, la logique métier, etc.) doit être adapté au modèle de votre base de données. Dans cet article, je mentionne que le code client interagissant avec la base de données doit fonctionner en se basant sur le modèle de données, de sorte que lui-même ne reproduise pas le modèle de base de données au statut de « premier classe ». Cette logique est généralement située au niveau d'accès aux données de votre client.

Dans les architectures à deux niveaux, qui existent encore par endroits, ce type de modèle système peut être le seul possible. Cependant, dans la plupart des systèmes, le niveau d'accès aux données me semble être une « sous-système », encapsulant le modèle de la base de données.

Exceptions

Il existe des exceptions à toute règle, et j'ai déjà mentionné que l'approche de priorité de la base de données et de génération de code source peut parfois être inappropriée. Voici quelques-unes de ces exceptions (d'autres peuvent éventuellement exister) :

• Lorsque le schéma est inconnu et doit être ouvert. Par exemple, vous êtes un fournisseur d'outils qui aide les utilisateurs à naviguer dans n'importe quel schéma. Ouf. Ici, il n'y a pas de génération de code. Mais, tout de même - la base de données avant tout.
• Lorsque le schéma doit être généré à la volée pour résoudre un certain problème. Cet exemple semble être une version légèrement enjouée du pattern entity attribute value, c'est-à-dire que vous n'avez vraiment pas de schéma clairement défini. Dans ce cas, il est souvent même impossible d'être certain qu'un SGBD vous conviendra.

Les exceptions sont par nature exceptionnelles. Dans la plupart des cas liés à l'utilisation d'un SGBD, le schéma est connu à l'avance, il est à l'intérieur du SGBD et constitue la seule source de « vérité », et tous les clients doivent avoir des copies dérivées de celui-ci. Idéalement, un générateur de code devrait être impliqué.

Source : habr.com