Geek Answers Handbook

Should I not use LINQ for objects because Microsoft can change it?

I got an argument with an employee about using LINQ to Objects (IEnumerable, not IQueryable) in our C # code. I used LINQ, and he said that we should not use the external provider (Microsoft) code in our code, but we should wrap it ourselves in our own abstraction layer.

Now I understand this methodology for use where you have a third-party dll without a name that can go out of business next week or when you work with database calls (i.e. return a common data provider, not SQL or Oracle) but, in my opinion, LINQ syntax is too good / elegant / readable for Microsoft to abandon it in the next 10 years. This is about the same as ToString ("Hello {0}", firstName); functionality.

I can reject the arguments and implement my own LINQ library, which calls the standard LINQ methods under covers, but doesn't that do it? Plus, I could only use extension methods, I have no idea how to do this:

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

What will be your argument for or against using LINQ for objects (IEnumerable extension methods)?

+5
source share
5 answers

Your friend is wrong. LINQ was the flagship feature of C # 3.0 and does not leave the language. There is always a chance that MS will no longer support C # (although I seriously doubt it), but as long as C # exists, there will be LINQ.

Also consider in which assembly LINQ-to-objects: extension methods are located System.Core.

+12
source

He is completely wrong.
This argument is applicable only when working with interchangeable components, such as database platforms.

Microsoft is extremely careful to avoid making changes to .Net; they cannot refuse LINQ.

, (from x in y) - , .
, .

LINQ to Objects, LINQBridge ( .Net 2.0, LINQ) EduLINQ ( )

+10

LINQ, , (Microsoft) , .

(.. #). , #. , Microsoft. .

+8

, ADO.NET : .

LINQ to Objects ( ): .

+3

, , :

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

, , .

... ...

0

More articles:


All Articles