Hier soir, nous avons présenté notre approche et une démonstration de notre produit, devant la communauté Alt.Net.
Il y avait une douzaine de personnes, je n'ai pas retenu tous les noms, mais les fidèles étaient là.
En introduction, Julien a présenté en introduction le nouveau site, visible
ici
Nous avons souhaité présenter l'esprit de notre approche, d'un point de vue développement, plutôt que les aspects Marketing et Business de notre produit.
Les échanges ont été passionnés, surtout lorsqu'on a abordé notre vision non objet du domaine métier. En quelques mots, notre point de vue sur le sujet se résume ainsi: la séparation Technique/Métier doit être mieux réalisée qu'elle ne l'est actuellement. Les considérations techniques sont connues d'avance et sont plutôt rigides, les considérations métiers ne sont pas connues d'avance, elles sont floues et sujet à interprétation, et l'approche objet ne s'adapte pas bien à ce contexte. Une approche orientée Données Relationnelles, avec l'usage du DataSet comme conteneur de données, est plus appropriée. Nous heurtons évidemment les adeptes d'une approche OO où les classes métiers sont typées, connues d'avance et rigides.
La question de l'ORM était au centre du débat. Nous ne sommes pas ORM, en ce sens que nous n'avons pas de O. Notre vision est que l'importance est centrée sur la caractéristique relationnelle du Métier, et non sur sa caractéristique Objet, qui est une invention du développeur, et dont le fonctionnel n'a aucune idée. Notre schéma vise à centrer l'essentiel sur cette représentation, et nous avons bien un mapping avec le stockage physique qui permet de récupérer les données en quelques lignes de code assez simple, et de les sauvegarder sans écrire aucune ligne de code.
D'autres points ont été abordées, comme la gestion de la configuration. En transformant une grande partie du code en configuration déclarative (qui s'exprime par un DataSet sérialisé en XML), se pose la question de la maintenance de ces données (Gestion de Version, Diff, Merge, conflits, ...). Je pense qu'elle n'est pas comparable aux mêmes problématiques posées avec du code. La configuration d'une Vue, se réalise en quelques minutes, et est relativement simple. Je n'envisage pas - mais je me trompe peut être - le scénario où plusieurs personnes travaillerons en même temps sur la même configuration d'une Vue. En ce qui concerne l'historique, je n'ai pour l'instant pas eu recours à naviguer dans l'historique de ma configuration (la configuration de notre outil Binding Studio comporte 89 vues, et je n'ai pas eu encore l'occasion d'être confronté à ce problème). Quoi qu'il en soit, il s'agit de configuration XML, et si c'est relativement pénible à lire, nous pourrons tout à fait envisager d'outiller notre produit pour faciliter la gestion dans ce sens.
Enfin, je regrette un peu de ne pas avoir montré, faute de temps, le petit scénario de "Respond to Change", que j'avais prévu, et qui consistait à rajouter un noeud de SubCategory dans l'arborescence des Produits. Cela se fait en quelques clics (on m'a fait remarqué qu'il y avait beaucoup de clics dans l'usage de notre produit, et je suis d'accord, mais je maintiens qu'il est plus efficace et plus facile de faire des clics que d'écrire du code). Il y a également beaucoup de points que l'on a pas évoqués du tout (sauvegarde des données, validateurs, données temporelles, Ajax).
Pour conclure, c'était très riche en échange, on sent que notre approche non objet bouscule les idées reçues, ce à quoi nous nous attendions. A nous de continuer à faire nos preuves sur des projets concrets.
Les slides de la présentation sont disponibles sur SlideShare.