Cela faisait déjà un petit moment que l'on se posait la question. Le DataSet allait il être porté en SilverLight ou non ? Microsoft avait plusieurs fois tourné autour du pot et quelques voix timides et éparses (dont la nôtre) avaient manifesté son intérêt pour le portage, lors de la wish list de SilverLight v2.
En vain, l'équipe d'ADO.NET vient d'annoncer il y a quelques jours que le DataSet ne serait pas porté en SilverLight. Pour rassurer les adeptes du DataSet, forcément déçus, ils proposent 3 alternatives pour construire ce qu'ils appellent des "data-centric applications" (un jour, il faudra qu'on m'explique quelles applications ne sont pas data-centric ?):
ADO.Net Services n'a malheureusement que très peu de rapport avec ce qu'on peut faire avec un DataSet. Disposer des opérations CRUD d'une Table avec une URL, est certainement un progrès et on peut s'en réjouir, mais ca ne suffit pas, car on a perdu beaucoup d'informations en route. Le besoin de travailler avec plusieurs tables et des relations n'est pas couvert. Or qui d'autre que le DataSet manie à la perfection ces considérations ?
RIA Services, n'est pas encore officiellement annoncé, et on ne sait pas si SilverLight 3 comportera cette brique. Mais de quoi s'agit-il exactement ? Je retranscris ici la définition fournie par MS:
Microsoft .NET RIA Services simplifies the traditional n-tier application pattern by bringing together the ASP.NET and Silverlight platforms. The RIA Services provides a pattern to write application logic that runs on the mid-tier and controls access to data for queries, changes and custom operations. It also provides end-to-end support for common tasks such as data validation, authentication and roles by integrating with Silverlight components on the client and ASP.NET on the mid-tier
Ce qui signifie plus ou moins, en tout cas, ce que j'en comprends : on va pouvoir appeler du code serveur facilement, comme s'il s'agissait d'une application ASP.NET, et partager code client et serveur de façon plus ou moins transparente. Si on peut comprendre l'intérêt pour une validation de données, je ne vois absolument aucun rapport avec le DataSet.
Web Services. Donc on en revient, à développer à la main, toutes les opérations de changement. Je ne suis pas certain qu'on ait beaucoup gagné au change.
Bref, c'est encore l'Orienté Objet qui domine, et qui va inviter le développeur à écrire plus de code rigide et compliqué pour faire des choses simples. Dommage que Microsoft n'ait pas imaginé que le DataSet restait un choix de développement. Le portage dans SilverLight ne devait pas être si compliqué pour eux et c'est vraiment une occasion ratée, surtout en proposant des alternatives qui n'ont pas grand chose à voir.
De notre côté, plus nous avançons et plus l'évidence nous saute aux yeux. Le DataSet est une pièce incontournable d'une bonne architecture 3 tiers, qui offre tout un tas de services indispensables dont nous avons déjà parlé à de nombreuses reprises (serialisation, track changes, typage faible, filtre, tri, binding, relations, copie de données, ...). Ne pas en bénéficier et c'est autant de choses qu'il faudra refaire à la main. Le DataSet offre plus d'avantages qu'il n'a d'inconvénients.
Cela nous demandera donc un peu plus de travail pour atteindre SilverLight (si MS avait porté le DataSet, cela nous aurait fait gagner du temps), mais, comme on l'a déjà fait plus ou moins en javascipt, on devrait être capable de le refaire en C# pour SilverLight, sans trop de difficultés. Et de montrer que le DataSet est un puissant outil, à la fois pour l'accès aux données et pour le DataBinding côté client, et qu'il peut être utilisé sans trop de difficultés.