Question

我和一位同事讨论过在我们的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 };

你的论点是什么，赞成或反对使用LINQ to objects（IEnumerable扩展方法）？

Answer 1

你的朋友错了。 LINQ是C＃3.0的旗舰功能，不会离开该语言。 MS总是有机会停止支持C＃（尽管我非常怀疑），但只要有一个C＃，就会有LINQ。

另外，请考虑LINQ-to-objects扩展方法在哪个程序集中放置：System.Core。

Answer 2

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

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

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

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

Answer 3

我使用的是LINQ，他说我们不应该在代码中使用外部供应商的（Microsoft）代码，但我们应该将它自己包装在我们自己的抽象层中。

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

Answer 4

包装像ADO.NET或第三方库这样的图层依赖：值得考虑的想法。

将LINQ包装到对象（框架和游戏规则改变者的核心部分）：糟糕的主意。

Answer 5

也许你的同事只是觉得更多正确：

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

无论如何，我认为你的同事的担忧是完全没有根据的。

... 有趣 ...

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

5 个答案: