我和一位同事讨论了在我们的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(用于教育目的)
我使用的是LINQ,他说我们不应该在代码中使用外部供应商的(Microsoft)代码,但我们应该将它自己包装在我们自己的抽象层中.
它是语言的核心部分(即C#语言规范的一部分).只要C#在身边,它就会存在.对它的改变将是破坏性的变化,对微软的客户来说将是巨大的成本.他们不打算这样做.
| 归档时间: |
|
| 查看次数: |
395 次 |
| 最近记录: |