Un nouveau sujet de débat pour le microcosme: SDO
Les gens de JDO sont incroyables...
Revenons dans le passé.
Le marché souhaitait représenter les données sous forme d'objets du langage, et les persister sans trop rompre avec cette philosophie; or les api des sgdbr parlent plutôt requête textuelle, résultat générique sous forme de tableau / ligne / colonne.
Les objetistes répondirent, avec les SGBDOO et leurs apis propriétaires, puis avec quelques standards, puis avec JDO dans le monde Java.
Oui mais les applis, ce n'est pas que la persistance, c'est aussi et surtout des services !! et enfin de l'interopération avec des gui ou d'autres services.
Le marché est rappellé à la barre; oui, ça l'intéresse aussi de pouvoir détacher des données chargées, les confier à leur couche présentation qui les modifie. De connaître facilement l'historique des changements de l'utilisateur en retour, de réattacher à la persistence des grappes de données modifiées, et hop, si ça pouvait aussi répercuter les modifs en base tout seul...
Et là, je tombe des nues : les objetistes nous pondent SDO.
Je dis les objetistes, parce que les premiers ponts implémentés sont vers... JDO ! (ah, ah, piégés !!)
Je dis je tombe des nues, parce que SDO c'est du dataset générique et non de l'objet du langage (mes objets du langage, vous en avez fait quoi bandes de malfrats ???); mais c'est du bon vieux "dataset" détaché façon ADO que vous nous faites là ??? (qui existe depuis 1998 notons le).
Bien sûr, je pourrai être plus mesuré.
Dire que l'argument suivant pourrait être retenu : le business côté serveur a besoin d'objets du langage mais la prez pourrait s'en passer, ça lui va bien, elle, de la grappe générique truffée de metadata. Mouais.
Que les EJB3 et Hibernate qui supportent le détachement, sont incomplets pour aider à reconstituer un historique, fournir du metadata sur le typage... Mouais.
Et bien non.
Je vais plutôt dire: vous ne perdez rien pour attendre. Attendez que Gavin King s'en mêle. Les objetistes, il les connait bien. Il connait leur faible propention au pragmatisme, leur faible fréquentation des plateaux de dev "ordinaires". Comme Hibernate a répondu à JDO avec une approche plus pragmatique et simple avec l'approche POJO, je suis certain que les features de SDO pour les couches services et présentation sont implémentables dans des outils simples, en particulier qui conserve le POJO métier.
POJOistes réjouissez vous, vous avez une nouvelle terre à conquérir.
Note: pour vous convaincre de la JDOisation rampante de SDO (pour reprendre l'expression des syndicats de cheminot) observez les interventions sur ce thread de The Server Side; plus objectivement, on note aussi dans la page SDO d'IBM (google.feelLucky("SDO service data objects introduction")) et dans d'autres sources que JDO est plus supporté que Hibernate ou EJB3. Tiens, comme par hasard, des outils qui supportaient déjà le détachement...
Revenons dans le passé.
Le marché souhaitait représenter les données sous forme d'objets du langage, et les persister sans trop rompre avec cette philosophie; or les api des sgdbr parlent plutôt requête textuelle, résultat générique sous forme de tableau / ligne / colonne.
Les objetistes répondirent, avec les SGBDOO et leurs apis propriétaires, puis avec quelques standards, puis avec JDO dans le monde Java.
Oui mais les applis, ce n'est pas que la persistance, c'est aussi et surtout des services !! et enfin de l'interopération avec des gui ou d'autres services.
Le marché est rappellé à la barre; oui, ça l'intéresse aussi de pouvoir détacher des données chargées, les confier à leur couche présentation qui les modifie. De connaître facilement l'historique des changements de l'utilisateur en retour, de réattacher à la persistence des grappes de données modifiées, et hop, si ça pouvait aussi répercuter les modifs en base tout seul...
Et là, je tombe des nues : les objetistes nous pondent SDO.
Je dis les objetistes, parce que les premiers ponts implémentés sont vers... JDO ! (ah, ah, piégés !!)
Je dis je tombe des nues, parce que SDO c'est du dataset générique et non de l'objet du langage (mes objets du langage, vous en avez fait quoi bandes de malfrats ???); mais c'est du bon vieux "dataset" détaché façon ADO que vous nous faites là ??? (qui existe depuis 1998 notons le).
Bien sûr, je pourrai être plus mesuré.
Dire que l'argument suivant pourrait être retenu : le business côté serveur a besoin d'objets du langage mais la prez pourrait s'en passer, ça lui va bien, elle, de la grappe générique truffée de metadata. Mouais.
Que les EJB3 et Hibernate qui supportent le détachement, sont incomplets pour aider à reconstituer un historique, fournir du metadata sur le typage... Mouais.
Et bien non.
Je vais plutôt dire: vous ne perdez rien pour attendre. Attendez que Gavin King s'en mêle. Les objetistes, il les connait bien. Il connait leur faible propention au pragmatisme, leur faible fréquentation des plateaux de dev "ordinaires". Comme Hibernate a répondu à JDO avec une approche plus pragmatique et simple avec l'approche POJO, je suis certain que les features de SDO pour les couches services et présentation sont implémentables dans des outils simples, en particulier qui conserve le POJO métier.
POJOistes réjouissez vous, vous avez une nouvelle terre à conquérir.
Note: pour vous convaincre de la JDOisation rampante de SDO (pour reprendre l'expression des syndicats de cheminot) observez les interventions sur ce thread de The Server Side; plus objectivement, on note aussi dans la page SDO d'IBM (google.feelLucky("SDO service data objects introduction")) et dans d'autres sources que JDO est plus supporté que Hibernate ou EJB3. Tiens, comme par hasard, des outils qui supportaient déjà le détachement...
Commentaires