| masklinn |
hephaestos a écrit :
Il existe quoi dans la nature comme moyen d'accéder à des bases de données depuis le code applicatif ? J'ai fait un peu d'entity framework avant, c'était mon premier contact avec une base de données : on écrit du code naturel, les données sont considérées comme des collections natives et le code est converti en requêtes au runtime, je trouve ça chouette. Ici on n'a rien de tel, du coup on doit avoir des accès explicites. Je trouve ça tellement horrible j'ai du mal à croire que ce soit l'état de l'art... Le pire je trouve c'est quand on se retrouve à injecter du SQL (synthétisé avec des constexpr en C++) ; c'est déjà compliqué de lire du SQL. Si en plus il fait comprendre le code qui le synthétise et savoir deviner comment ça se comportera au runtime je trouve ça difficilement acceptable. Mais bon, j'ai l'impression que je suis le seul que ça dérange. Je suis une chochotte, ou j'ai raison ? Vous gérez comment ?
|
En faisant pas de C++ [:jar jar] Je présume que EF est un ORM, donc ça a l'avantage d'être très haut niveau et naturel (s'il est bon en tout cas) mais ça demande beaucoup d'infra en dessous, et ça tend à être inflexible et inefficace (genre il est difficile d'optimiser tes requêtes au maximum ou de tirer un maximum des spécificités de la DB). Je suis pas sûr qu'un ORM se trouve pour du C++, et pour les raisons au dessus plus les langages sont bas niveau plus les ORMs ont tendance à donner des boutons (et généralement les ORMs marchent par réflection, ou alors il faut des montagnes de codegen, c'est d'autant plus difficile en C++). Faut probablement plus regarder du côté des DAO (pour l'organisation) et des query builders (pense linq for sql).
Ou bien le projet a démarré petit et personne a remis le problème en question. el muchacho a écrit :
Vous pouvez faire des procédures stockées, les requêtes sont stockées en base au lieu d'être générées coté client. La base présente alors une API de requêtes possibles que le client appelle. Cette manière de faire est assez élégante, je touve, mais le déploiement est plus compliqué puisqu'il faut le faire dans la base de données et bien sûr s'assurer de la compatibilité entre le code client et la base.
|
C'est une approche qui ne vaut vraiment le couop que si tu as plusieurs clients qui tapent dans la base et que tu veux contrôler les accès, ou plus généralement que tu fais pas confiance aux clients mais que tu veux / peux pas avoir de broker (tes stored procs te servent d'API), mais pour une relation 1:1 c'est ultra chiant, la moindre interrogation de db impose d'aller mettre à jour le schéma pour ajouter ou éditer une procédure stockée habituellement codée dans un langage bancal que t'as pas envie de toucher. Et au final t'y gagnes rien: ta proc stockée pourrait être une fonction / méthode, t'aurais moins d'overhead à l'appel, moins de chances de te planquer, et plus de vérifications.
|