我不应该使用LINQ到对象,因为微软可能会改变它吗?

Dar*_*ryl 5 c# linq

我和一位同事讨论了在我们的C#代码中使用LINQ to Objects(IEnumerable,而不是IQueryable)的问题.我使用的是LINQ,他说我们不应该在代码中使用外部供应商的(Microsoft)代码,但我们应该将它自己包装在我们自己的抽象层中.

现在我理解了这种方法,你可以使用下周可能会破产的无名第三方dll,或者当你处理数据库调用时(即返回一个公共数据提供者,而不是SQL或Oracle)特定的一个),但在我看来,LINQ语法太漂亮/优雅/可读让微软在未来10年内放弃.它很可能被删除为ToString("Hello {0}",firstName); 功能.

我可以放弃争论,并实现我们自己的LINQ库,它可以调用标准的LINQ方法,但是不是这样做了吗?另外我只能使用扩展方法,我不知道如何能够包装它:

from e in employees
select new { e.Name, e.Id };
Run Code Online (Sandbox Code Playgroud)

你的论点是什么,支持或反对使用LINQ对象(IEnumerable扩展方法)?

dle*_*lev 12

你的朋友错了.LINQ是C#3.0 旗舰功能,不会离开该语言.MS总是有机会停止支持C#(虽然我非常怀疑),但只要有一个C#,就会有LINQ.

另外,考虑LINQ-to-objects扩展方法所在的汇编:System.Core.


SLa*_*aks 10

他完全错了.
该参数仅适用于处理可替换组件,例如数据库平台.

微软非常小心避免在.Net中做出重大改变; 他们无法放弃LINQ.

为了回答您的其他观点,查询理解语法(from x in y)是一个转换为方法调用的编译器功能.
如果您编写自己的方法,编译器将很乐意使用它们.

已经有LINQ to Objects方法的第三方实现,例如LINQBridge(用于.Net 2.0,早于LINQ)或EduLINQ(用于教育目的)

  • 一切都可能改变.它只适用于改变的事情,并且处理变更的成本高于处理额外的抽象层的成本,这些抽象层试图保护您免受变更(包括设计,编写,测试和保持它). (2认同)

jas*_*son 8

我使用的是LINQ,他说我们不应该在代码中使用外部供应商的(Microsoft)代码,但我们应该将它自己包装在我们自己的抽象层中.

它是语言的核心部分(即C#语言规范的一部分).只要C#在身边,它就会存在.对它的改变将是破坏性的变化,对微软的客户来说将是巨大的成本.他们不打算这样做.

  • VB.NET是一种新语言,而不是VB6的下一个版本 (3认同)