L'auteur explique (en anglais) dans cet article pourquoi il a décidé d'écrire ce framework.
Bon allez je tente un résumé rapide :
- les bases de données relationnelles sont trop éloignées de l'orienté objet ce qui génère un code plus complexe que nécessaire ;
- les bases de données objets paraissent une bonne solution, orientée objet et proposant/masquant tout un système complexe pour améliorer les performances de la couche de persistance ;
- mais une base de donnée nécessite d'ouvrir puis de gérer une connexion à la base, ce qui génère encore une fois beaucoup de code inutile ;
- dans la majorité des cas les performances ne sont pas un problème car l'application n'aura probablement jamais assez d'utilisateurs/contenu pour dépasser les capacités d'une simple écriture sur le disque de l'objet sérialisé, l'important est d'avoir moins de code à écrire.
Attention il ne dit pas que c'est la solution universelle, juste que pour un prototype ou pour une petite application métier, les performances seront suffisantes et le coût de développement sera moindre.
[^] # Re: Seaside et Pharo
Posté par ... a little wood elfe . En réponse à la dépêche Les technos web cools du moment. Évalué à 1.
Vu que tu n'as pas donné de lien pour ce point, je propose SandstoneDb. Une API de persistance pour SmallTalk dans le style Active Record mais sans base de donnée :
http://onsmalltalk.com/sandstonedb-simple-activerecord-style(...)
L'auteur explique (en anglais) dans cet article pourquoi il a décidé d'écrire ce framework.
Bon allez je tente un résumé rapide :
- les bases de données relationnelles sont trop éloignées de l'orienté objet ce qui génère un code plus complexe que nécessaire ;
- les bases de données objets paraissent une bonne solution, orientée objet et proposant/masquant tout un système complexe pour améliorer les performances de la couche de persistance ;
- mais une base de donnée nécessite d'ouvrir puis de gérer une connexion à la base, ce qui génère encore une fois beaucoup de code ;
- dans la majorité des cas les performances ne sont pas un problème car l'application n'aura probablement jamais assez d'utilisateurs/contenu pour dépasser les capacités d'une simple écriture sur le disque de l'objet sérialisé, l'important est d'avoir moins de code à écrire.
Attention il ne dit pas que c'est la solution universelle, juste que pour un prototype ou pour une petite application métier, les performances seront suffisantes et le coût de développement sera moindre.