par
Cyrano » 23 avr. 2008, 19:33
Comme je suis un peu concerné par le sujet, je vais reproduire ici l'essentiel de ce qui a poussé
Hywan à poster ce sujet.
En essayant de voir le problème globalement, j'en arrive à une première conclusion quant aux types de développement que l'on peut mener. Ils sont essentiellement de deux types. D'une part on peut développer des outils d'aide à la conception, d'autre part on peut mettre au point des outils de production.
Dans le cas des outils de production, il m'apparaît prioritaire de s'interroger sur la pertinence du travail lorsqu'on veut créer telle ou telle nouvelle fonctionnalité. L'intérêt de la création d'un outil d'ORM à cet égard me semble de plus en plus incertain. Un tel outil en effet doit permettre d'améliorer les performances techniques globales de l'application créée. Le but à poursuivre devrait donc être de limiter l'utilisation des ressources système autant que faire se peut.
Le but général de l'ORM est d'automatiser au maximum un système de requêtage SQL en établissant une sorte de cartographie de base de données dans le but de générer dynamiquement les requêtes nécessaires à un moment ou un autre dans le déroulement du programme. Si ce but peut faciliter le développement de cette application, il m'apparaît en revanche que non seulement il n'améliore pas les performances mais également que ça va la ralentir en utilisant davantage de ressources. L'intérêt d'un tel système tombe complètement si on réalise qu'en fin de compte, pour une application donnée, le modèle de données n'évoluera plus ou pratiquement plus. La structure des tables, vues et autres procédures stockées ne subira plus de modifications en dehors de corrections ou d'ajouts ponctuels de fonctionnalités nouvelles. Dans cette optique, il ne faut pas un doctorat en mathématiques quantique pour se rendre compte que refaire la cartographie à chaque nouvelle requête va complètement à l'encontre du but poursuivi à l'origine. Cette cartographie n'a besoin d'être générée qu'une seule fois au lancement puis éventuellement refaite en cas de modification d'un élément du modèle de données. Un outils d'ORM ne peut, en conclusion, que se classer comme un outil de conception et d'aide au développement. Et l'intégrer dans un quelconque framework devient également un non-sens.
Voilà, les avis et/ou objections seront bienvenus
Comme je suis un peu concerné par le sujet, je vais reproduire ici l'essentiel de ce qui a poussé [b]Hywan[/b] à poster ce sujet.
[quote="Ailleurs, Cyrano"]En essayant de voir le problème globalement, j'en arrive à une première conclusion quant aux types de développement que l'on peut mener. Ils sont essentiellement de deux types. D'une part on peut développer des outils d'aide à la conception, d'autre part on peut mettre au point des outils de production.
Dans le cas des outils de production, il m'apparaît prioritaire de s'interroger sur la pertinence du travail lorsqu'on veut créer telle ou telle nouvelle fonctionnalité. L'intérêt de la création d'un outil d'ORM à cet égard me semble de plus en plus incertain. Un tel outil en effet doit permettre d'améliorer les performances techniques globales de l'application créée. Le but à poursuivre devrait donc être de limiter l'utilisation des ressources système autant que faire se peut.
Le but général de l'ORM est d'automatiser au maximum un système de requêtage SQL en établissant une sorte de cartographie de base de données dans le but de générer dynamiquement les requêtes nécessaires à un moment ou un autre dans le déroulement du programme. Si ce but peut faciliter le développement de cette application, il m'apparaît en revanche que non seulement il n'améliore pas les performances mais également que ça va la ralentir en utilisant davantage de ressources. L'intérêt d'un tel système tombe complètement si on réalise qu'en fin de compte, pour une application donnée, le modèle de données n'évoluera plus ou pratiquement plus. La structure des tables, vues et autres procédures stockées ne subira plus de modifications en dehors de corrections ou d'ajouts ponctuels de fonctionnalités nouvelles. Dans cette optique, il ne faut pas un doctorat en mathématiques quantique pour se rendre compte que refaire la cartographie à chaque nouvelle requête va complètement à l'encontre du but poursuivi à l'origine. Cette cartographie n'a besoin d'être générée qu'une seule fois au lancement puis éventuellement refaite en cas de modification d'un élément du modèle de données. Un outils d'ORM ne peut, en conclusion, que se classer comme un outil de conception et d'aide au développement. Et l'intégrer dans un quelconque framework devient également un non-sens.[/quote]
Voilà, les avis et/ou objections seront bienvenus :)
