Les technologies de l'information modernes étonnent par leur puissance, elles sont dépassées par les opportunités qui s'ouvrent, elles sont découragées par la perfection technique qui leur est inhérente, mais il y a un point ridicule sur lequel l'informatique se casse les dents encore et encore. Afficher les données utilisateur de la base de données, obtenir des informations de sa part, les replacer dans la base de données, afficher le résultat. Champs de saisie, boutons, coches, inscriptions - il semblerait qu'ils puissent être tellement prohibitifs d'exiger des constructions déroutantes comme des cadres au-dessus des moteurs de modèles au-dessus des cadres au-dessus des transpilateurs? Et pourquoi, malgré tous les efforts énormes, nous avons le fait que les exemples de jouets dans le tutoriel, bien sûr, sont fabriqués facilement et agréablement, mais dès que la boîte à outils rencontre les vrais problèmes de la vie réelle ... comment dire plus doucement ... avec une complexité croissante des tâches à résoudre, il y a une forte non-linéarité d'augmentation difficultés de mise en œuvre. Eh bien, il s'agirait de quelque chose de vraiment déroutant au niveau de la physique théorique ou de la technologie spatiale, car il n'y en a pas de toute façon - des boutons et des coches. Pourquoi cette absurdité continue-t-elle d'empoisonner la vie des citoyens et des collectifs de travail pendant des décennies?
Les raisons, probablement, comme toujours, sont nombreuses. Ils méritent probablement tous d'être pris en considération d'une manière ou d'une autre, mais ici et maintenant, nous parlerons de la tâche ORM (Object-Relational Mapping), qui se trouve toujours derrière certains de ces «boutons et coches» sous une forme ou une autre.
Que savons-nous de l'ORM
- Stocker des données dans des tables relationnelles ne veut pas dire que c'est une question très simple, mais en général, l'idée et les modalités de son application sont assez claires et bien étudiées.
- Avec la programmation d'objets, tout n'est pas si bon (il y a plusieurs approches concurrentes), mais en général, avec la mise en œuvre et l'application des technologies, tout est aussi plus ou moins clair.
- À la fois cela et un autre - sur les données, leur stockage et leur traitement. C'est en fait à peu près la même chose.
- Il nous semble logique qu'il devrait y avoir un pont simple, compréhensible, pratique, prévisible et universel entre les deux mondes.
- Et chaque fois que nous trouvons ce pont facilement, mais le malheur, sa simplicité, sa compréhensibilité, sa commodité, sa prévisibilité et son universalité ne fonctionnent pas au-delà de simples exemples tirés de tutoriels.
- Tout le monde souffre: les développeurs, qui doivent faire beaucoup de travail extrêmement ennuyeux, et les utilisateurs qui doivent se battre avec des logiciels maladroits, et l'entreprise, dont la réalisation des besoins s'avère soudainement insupportablement longue et coûteuse, et l'industrie dans son ensemble.
- J'ai vu de nombreux ORM différents, mais je n'en ai pas vu de bons. Autrement dit, celui qui, au-delà des simples exemples, ne se transforme pas en fardeau et en lit procrustéen.
Pourquoi tout est-il si bizarre
La base idéologique de la théorie et de la pratique des bases de données relationnelles est le calcul des prédicats, c'est-à-dire une branche des mathématiques. Quant à la POO, une base idéologique similaire y fait défaut. On peut essayer de formuler l'idée de base de la POO comme ceci: puisque le monde est constitué d'objets, il serait commode de le modéliser, ce monde, en créant des objets à l'intérieur d'un système logiciel. En ce sens, deux erreurs à la fois. Premièrement, le monde lui-même ne consiste pas et n'a jamais été constitué d'objets. Deuxièmement, je suis désolé, mais pourquoi le programme doit-il simuler le monde? Autrement dit, nous avons une déclaration conceptuellement incorrecte, parfaitement complétée par une déclaration dénuée de sens du problème.
Tout ORM est une tentative d'étirer clairement la correspondance unifiée entre, en fait, la branche des mathématiques et un ensemble vague de pratiques diverses, basées sur des considérations de commodité, des approches historiquement établies, et aussi souvent sur des légendes, des opinions des autorités et simplement des idées fausses. In vitro, il peut être fait pour fonctionner, mais in vivo, il est voué à paraître pathétique et à apporter plus de chagrin que de joie.
Sur l'inévitabilité de l'orientation des objets
Néanmoins, la nécessité de l'orientation objet de notre logiciel est notre réalité inévitable. Cette inévitabilité est basée principalement sur le fait que fonctionner avec des objets est l'essence et le fondement de l'une de nos activités. Le monde lui-même ne se compose pas d'objets, mais pour comprendre quelque chose dans ce monde et faire quelque chose avec ce monde, nous déclarons nous-mêmes ses parties en tant qu'objets, les appelons des noms, essayons de comprendre leur comportement, appliquons à lui s'efforce d'obtenir les résultats souhaités. C'est notre façon de fonctionner, il est impossible de la quitter et ce n'est pas nécessaire. Tout est objet, non pas parce qu'il l'est vraiment, mais parce que nous ne pouvons pas faire autrement. Ce qui ne peut en aucun cas être un objet se situe complètement en dehors des limites de notre capacité à comprendre et ne peut pas faire l'objet de nos efforts.
Même si le programme est écrit sans utiliser de techniques OOP, il contient inévitablement des objets (au sens large du terme), en manipulant ce que le développeur résout son problème - variables, types de données, opérateurs, algorithmes, constructions syntaxiques, fonctions, modules. Du point de vue de l'utilisateur, le programme dispose également d'un ensemble d'objets avec lesquels il interagit - boutons, étiquettes, champs de saisie, pages, sites et l'ensemble du système.
Ce que nous stockons dans nos bases de données
Comme mentionné ci-dessus, les bases de données relationnelles sont basées sur le calcul des prédicats. Un prédicat est un fait formulé et, dans notre cas, stocké sur un support. Juste au cas où, je note que la base de données relationnelle n'est pas seulement et pas tellement sur les relations entre les tables par des clés étrangères. Dans la terminologie appropriée, les relations sont ce que nous appelons simplement des tables. Autrement dit, même si votre base de données n'a qu'une seule table avec deux colonnes (par exemple, le nom et le numéro de téléphone), vous disposez déjà d'une base de données relationnelle qui établit la relation entre deux ensembles, dans ce cas, des ensembles de noms et de numéros de téléphone.
Une base de données relationnelle ne stocke pas d'objets, elle stocke des faits. Les faits stockés, bien sûr, ont un objet («de quoi s'agit-il?»), Et lorsque nous essayons d'apprendre au système à répondre à cette question, nous avons des entités, c'est-à-dire des objets auxquels des faits sont associés. Si vous travaillez correctement, la structure de notre base est née d'une série de réponses à la question «quel genre de faits avons-nous l'intention de garder?», Et ce n'est qu'à l'étape suivante que nous obtenons quelque chose qui ressemble à des objets qui donnent des faits à l'objectivité. Vous pouvez, bien sûr, concevoir «à partir d'objets», mais je ne recommanderais pas de le faire, sauf dans les travaux de laboratoire sur des sujets qui ne sont pas directement liés à la conception de bases de données. Le danger de lourdes erreurs architecturales est trop grand. De plus, c'est au moins gênant.
Une petite digression sur les bases de données d'objets. Une pensée très simple: si nous sommes fatigués des problèmes d'ORM, alors peut-être devrions-nous faire quelque chose avec la partie qui est "R"? Que notre base de données ne soit pas un monstre relationnel difficile et exigeant, mais quelque chose de jeune à la mode spécialement conçu pour stocker des objets. Une sorte de base NoSQL schématique, par exemple. Mais au final, il s'avère soudain que les ORM de type NoSQL sont encore plus maladroits et contre nature que les bons vieux SQL. Quoi qu'il en soit, nous pouvons avoir et utiliser avec plaisir un SGBD sans circuit, mais il n'y a pas de données sans circuit dans la nature. Il n'y a rien de plus impuissant, irresponsable et immoral que l'ORM pour les bases de données sans circuit.
Bon ORM
Un bon ORM est l'ORM manquant. Eh bien, sérieusement. Regardez l'un de vos systèmes ORM et essayez honnêtement de répondre à votre question: quels sont les avantages de ce monstre? Quelle est la raison de son utilisation, sauf pour les promesses de bonheur non tenues et les préjugés discrédités à plusieurs reprises? Bien sûr, il y a des choses utiles, mais quelles sont-elles dans le contexte des déformations architecturales introduites et des problèmes de performance qui surgissent constamment à l'improviste?
En règle générale, l'API de base de données «bas niveau» est simple, pratique, complète et cohérente. Habituellement, suffisamment de doigts pour répertorier toutes les fonctionnalités. Les apprendre n'est pas une nouvelle divine quelle tâche.
Je vais essayer d'esquisser un ensemble de principes architecturaux qui vous permettent de mapper des objets à une base de données sans utiliser ORM:
- Nous stockons les faits, opérons sur des objets. N'oubliez pas que la base de données stocke des faits et que les modèles d'objets impliqués dans le traitement des données sont des projections d'ensembles de faits de différents points de vue. Par exemple, pour l'exemple donné avec les noms et les numéros de téléphone, nous pouvons avoir la classe Abonent, pour laquelle plusieurs numéros peuvent être stockés, et aussi la classe PhoneNumber, pour laquelle plusieurs abonnés peuvent être définis (n'oubliez pas qu'en plus des numéros de mobile personnels, nous avons où il y a encore des téléphones d'appartement et de bureau). Et la table dans la base de données est juste celle qui définit la relation plusieurs-à-plusieurs entre plusieurs noms et numéros de téléphone. Juste deux projections différentes. Cette approche, soit dit en passant, évolue normalement vers des cas beaucoup plus complexes, vous permettant d'avoir des classes utiles dans le système comme, par exemple, "les ventes moyennes pour une période donnée selon une combinaison donnée de critères".
- Les faits sont projetés dans des objets et vice versa via une API orientée problème. Sans appliquer une solution qui se veut universelle. Si vous ne savez toujours pas comment composer des API pratiques, découvrez comment. Et surtout, apprenez-vous à les documenter immédiatement.
- Commandez avant tout. Si vous utilisez la version classique d'un SGBD avec un schéma de données rigide, ce schéma en lui-même met de l'ordre dans le travail avec les données. La structure supplémentaire codée par la structure des objets est simplement redondante. Si vous utilisez un SGBD sans schéma, vous devrez bien sûr faire quelques efforts pour vous assurer que votre base de données ne se transforme pas en une montagne d'ordures car les différents développeurs ont des idées différentes sur ce qui est stocké.
- Indépendance du SGBD (si nécessaire). Si la propriété d'ORM la plus intéressante pour vous est l'indépendance du SGBD, utilisez des outils spéciaux tels que ODBC, JDBC, ADO, ou si cela n'est pas possible, créez votre propre niveau d'abstraction. Ce n'est pas aussi difficile que cela puisse paraître au premier abord. Vous n'avez pas besoin de support pour absolument toutes les capacités de absolument tous les SGBD pour votre tâche, non?
- N'oubliez pas les aspects supplémentaires de l'utilisation des données. Tels que, par exemple, le partage de l'accès aux données (qui peuvent être arbitrairement complexes), la surveillance, la réplication, etc. Mais ici, j'ai de bonnes nouvelles pour vous: parce que dans votre ORM préféré, l'ajout. l'aspect est toujours mis en œuvre selon le principe «vous ne plairez pas à tout le monde, mangez ce que vous donnez», le rejet d'un service douteux avec lequel vous devez faire plus que coopérer s'avérera finalement être une décision stratégiquement correcte.
Total
L'ORM est un sujet très sensible pour notre industrie. À une époque où l'intelligence artificielle du cloud laboure la blockchain quantique, la grande majorité de la main-d'œuvre est occupée à visser la logique métier et une interface utilisateur aux bases de données. Des millions de lignes de code terrible, clouées avec des microscopes, la douleur et le désespoir accompagnent partout ce processus créatif. L'une des racines de cette triste situation est l'idée fausse extrêmement persistante qu'un ORM universel est en principe possible. Mais c'est impossible, et il y a une raison fondamentale à cela, qui ne peut être éliminée. La prise de conscience de ce fait est la première étape vers la sortie de ce cauchemar. Il existe un moyen de sortir, il existe des alternatives, mais vous devez d'abord vous rendre compte, ressentir et apprendre à garder le focus de l'attention.
PS Je m'excuse sincèrement auprès des frères de la profession qui ont investi beaucoup de temps et d'efforts dans la création de nombreux meilleurs universels dans le monde de l'ORM. Je suis vraiment désolée.