LINQ is a language feature, it's not necessarily a "technology" or "framework".
If you are using Entity Framework then you pretty much do have to use LINQ.
There are numerous LINQ providers for different data sources and you don't have to use most of them. For instance, LINQ to Objects is the provider for writing LINQ queries against standard arrays and collections. There's no need to use LINQ in that context if you don't want to, but it certainly can make your code more succinct. There is the LINQ to XML provider for querying XML data, LINQ to DataSet for querying ADO.NET DataTables, LINQ to SQL for direct access to SQL Server databases and many more. If you're using Entity Framework then you should be using LINQ to write your queries against the LINQ to Entities provider. While EF does support Entity SQL, that should really only be used in situations where it provides a genuine advantage. EF is intended to work with LINQ. Unlike LINQ to SQL, which Microsoft created to work with SQL Server specifically, any data source vendor can create an EF provider for that data source and then the LINQ to Entities provider interfaces with that. SQL Server is just one of many databases for which an EF provider exists.
Your subject like was "The Techonoliges (sic), Entity Framework and LINQ". I was just letting you know that LINQ is not a technology, much like the way generics or type inference is not a technology. I was just stating that LINQ is a language feature like generics and type inference.that is not really an answer to my question.
MSDN is a great source, but unfortunately, not always easily digestable.Is there some good books/articles out there presenting the best-practices ?
Equals()
for comparisons when C#'s idiomatic use is to use the "==" operator.I kind of agree, although: Language-Integrated Query (LINQ) (C#)Your subject like was "The Techonoliges (sic), Entity Framework and LINQ". I was just letting you know that LINQ is not a technology, much like the way generics or type inference is not a technology. I was just stating that LINQ is a language feature like generics and type inference.
Language-Integrated Query (LINQ) is the name for a set of technologies based on the integration of query capabilities directly into the C# language.
Well I hope when you say "Windows application" - that you actually are referring to a WPF/Xamarin type application and not Winforms. You should know that the recommendation coming from any techy with a brain, including Microsoft; are now advising people to move away from Winforms as it not only nearing EOL, It actually is EOL. The only reason its still supported is because many big companies are still running on Winforms itself. And porting said app to something like WPF isn't an option for some companies. This doesn't justify an excuse to use Winforms though. WPF is faster, more modern, scalable, robust, and a heck of a lot easier to build wicked themes for your application. This is achieved by writing Xaml, given you undergo the learning curve involved.I am about to create a Wniforms application.
I think; @jmcilhinney put it best in his post above. Linq not only makes for good readable code (providing you understand how to read/write it), but you can often do more in less code most of the time. Your question is really a matter of personal perspective, and the requirements of your app than it does have any relation to value itself.does that add any value for me ?
Perhaps not; but it's still a valid point which I assume @Skydiver thought might have been confusing you.that is not really an answer to my question.
I disagree with that statement by Microsoft's docs. I don't consider Linq to be a technology. It's merely nothing more than an extension to the C# language in my opinion. That article should be reworded.I kind of agree, although: Language-Integrated Query (LINQ) (C#)
LINQ is more than just the language keywords and syntax definitions. A LINQ provider is not an extension to the C# language. Support for the technology has been built into the language. I think that people can tend to focus on what you see on the surface and forget what's going on under the hood.I disagree with that statement by Microsoft's docs. I don't consider Linq to be a technology. It's merely nothing more than an extension to the C# language in my opinion. That article should be reworded.![]()
The C# and VB languages were both extended to support LINQ, with new keywords, etc. The LINQ that they were extended to support is not part of either language. Sure, we're all entitled to out own opinions about how certain words should be used and Microsoft isn't the arbiter of what everyone should think about programming but, if someone is learning to be a .NET developer then what Microsoft thinks is important, so telling them that Microsoft is wrong based on an opinion that is no more or less valid than another is probably a bit strong. That said, the original comment on this subject was that LINQ wasn't "necessarily" a technology, so that's not too definitive a statement on the subject.I look at Linq as an extension to c sharp.
Your subject like was "The Techonoliges (sic), Entity Framework and LINQ". I was just letting you know that LINQ is not a technology, much like the way generics or type inference is not a technology. I was just stating that LINQ is a language feature like generics and type inference.
MSDN is a great source, but unfortunately, not always easily digestable.
I can't give any advice on any books or articles specifically from the Java going to C# perspective. What I can say based on the C# code I've seen in my company written by others who are making that same Java to C# journey is that just transliterating from Java to C# doesn't make for very elegant looking or efficient C#. Just like there are idiomatic ways of doing things in Java, the idioms don't always translate well to C#. Off the top of my head is the Java compulsion to useEquals()
for comparisons when C#'s idiomatic use is to use the "==" operator.