Devrais-je ne pas utiliser LINQ pour les objets car Microsoft pourrait le changer ?

Question

J'ai eu une dispute avec un collègue à propos de l'utilisation de LINQ sur des objets (IEnumerable, pas IQueryable) dans notre code C#. J'utilisais LINQ, et il a dit que nous ne devrions pas utiliser le code d'un fournisseur externe (Microsoft) dans notre code, mais que nous devrions plutôt l'encapsuler nous-mêmes dans notre propre couche d'abstraction.

Maintenant, je comprends cette méthodologie pour une utilisation où vous avez une dll d'une tierce partie sans nom qui pourrait faire faillite la semaine prochaine, ou lorsque vous traitez avec des appels de base de données (c'est-à-dire en renvoyant un fournisseur de données commun, plutôt qu'un spécifique à SQL ou Oracle), mais à mon avis, la syntaxe LINQ est trop jolie/élégante/lisible pour que Microsoft l'abandonne dans les 10 prochaines années. Il est aussi susceptible d'être abandonné que la fonctionnalité ToString("Hello {0}", firstName);.

Je pourrais arrêter de discuter et mettre en place notre propre bibliothèque LINQ qui appelle les méthodes LINQ standard en interne, mais n'est-ce pas exagéré ? De plus, je pourrais seulement utiliser les méthodes d'extension, je n'ai aucune idée de comment encapsuler ceci :

from e in employees
select new { e.Name, e.Id };

Quel serait votre argument, pour ou contre l'utilisation de LINQ sur des objets (les méthodes d'extension IEnumerable) ?

Answer 1

Votre ami a tort. LINQ était la fonctionnalité phare de C# 3.0, et ne quittera pas le langage. Il y a toujours une possibilité que MS cesse de soutenir C# (bien que je doute fortement cela,) mais tant qu'il y a un C#, il y aura LINQ.

De plus, pensez à dans quelle assembly les méthodes d'extension LINQ-to-objects sont hébergées : System.Core.

Answer 2

Il a complètement tort.
Cet argument ne s'applique que lorsqu'il s'agit de composants fongibles, comme les plates-formes de base de données.

Microsoft est extrêmement prudent pour éviter de faire des changements radicaux dans .Net; il n'y a aucun moyen qu'ils abandonnent LINQ.

Pour répondre à vos autres points, la syntaxe de compréhension de requête (from x in y) est une fonction du compilateur qui est transformée en appels de méthode.
Si vous écrivez vos propres méthodes, le compilateur les utilisera volontiers.

Il existe déjà des implémentations tierces des méthodes LINQ to Objects, telles que LINQBridge (à utiliser avec .Net 2.0, qui précède LINQ), ou EduLINQ (écrit à des fins éducatives)

Answer 3

J'utilisais LINQ, et il a dit que nous ne devrions pas utiliser le code d'un fournisseur externe (Microsoft) dans notre code, mais que nous devrions l'envelopper nous-mêmes dans notre propre couche d'abstraction.

C'est une partie centrale du langage (c'est-à-dire une partie de la spécification du langage C#). Il sera présent aussi longtemps que C# sera présent. Des modifications à cela seraient des modifications majeures, et représenteraient un coût énorme pour les clients de Microsoft. Ils ne vont pas le faire.

Answer 4

Encapsuler une dépendance de couche comme ADO.NET ou une bibliothèque tierce : idée à considérer.

Encapsuler LINQ to Objects (partie centrale du framework et révolutionnaire) : mauvaise idée.

Answer 5

Peut-être que votre collègue pense simplement que c'est plus correct :

var result = employees.Select(e => new { e.Name, e.Id });

Quoi qu'il en soit, je pense que les inquiétudes de votre collègue sont complètement infondées.

...intéressant...