ADO.NET Data Services Hooking POC
Quand on utilise ADO.NET Data Services, le flux entre le client et le serveur va être réduit aux seules entités réellement souhaitées. Si on utilise l'Entity Framework avec ADO.Net Data Services, le flux entre le serveur et la base de données va également être réduit pour ne récupérer que les rows réellement souhaitées.
EF (particulièrement avec la première version) ne supporte pas tous les cas possibles. Par conséquent, il faut parfois développer ses propres classes d'entités qui vont encapsuler celles de l'Entity Framework.
Dans ce cas, avec ADO.NET Data Services, le flux entre le serveur et la base de données n'est pas optimisée. J'ai donc réaliser une POC pour couvrir ce scénario.
En faisant cela, je me suis rendu compte qu'ADO.NET Data Services Framework est extrémement "fermé". En effet quaisment toutes les classes / interfaces / enums sont internal. Je pense qu'il y aura d'ailleurs des changements dans la V2. Par exemple, il y a une interface internal System.Data.Services.Providers.IDataServiceProvider qui n'est implémentée que par System.Data.Services.Providers.BaseServiceProvider qui est une classe abstraite internale. Je pense que dans le futur, l'interface sera public sinon je ne vois pas son intérêt.
Pour pouvoir hooké ADO.NET Data Services, il y a deux choix:
·
tout réécrire
·
utiliser la réflection sur les classes internal
Le premier choix est le meilleur car comme les classes sont internal, MS peut en changer les membres dans le futur cependant, comme c'est juste une POC, j'ai choisi le deuxième qui est plus rapide.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
