Je comprends que System.DirectoryServices est une "couche au-dessus" de System.DirectoryServices.Protocols et abstrait une partie de la complexité.
Y a-t-il d'autres avantages, en termes de performances ou autres, à utiliser System.DirectoryServices.DirectorySearcher vs. System.DirectoryServices.Protocols.SearchRequest pour les requêtes LDAP depuis .NET?
Quels critères vous pousseraient à choisir l'une ou l'autre approche?
Après avoir travaillé avec les deux bibliothèques pendant les derniers mois, je peux vous dire qu'il existe de grandes différences, surtout si vous travaillez avec de gros ensembles de données. Ce billet de blog énumère quelques-uns des problèmes, et ayant travaillé avec des instances LDAP contenant plus de 500 000 entrées, je peux témoigner de son exactitude.
L'espace de noms System.DirectoryServices utilise beaucoup d'ADSI et de COM en sous-jacent, ce qui peut ajouter beaucoup de surcharge, en particulier avec la libération d'objets. Le System.DirectoryServices.Protocols interagit directement avec les API LDAP de bas niveau, vous offrant beaucoup plus de contrôle et une bien meilleure interopérabilité avec des annuaires non-Microsoft.
Si tout ce que vous essayez d'accomplir est une connectivité rapide et facile à une instance AD/ADAM/ADLDS pour des opérations relativement simples, il peut être utile de rester avec cet espace de noms - sinon, je vous recommanderais fortement d'investir le temps pour apprendre l'espace de noms Protocols. J'ai trouvé que cet article de MSDN a été d'une grande aide lorsque j'ai appris initialement - il couvre à peu près tout ce que vous aurez besoin de savoir.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
