Answered The Techonoliges, Entity Framework and LINQ

Inki

-
Joined
Aug 24, 2020
Messages
11
Location
Stockholm
Programming Experience
10+
Hi,

I am new to the microsoft technology stack.
Using MSSQL , .NET and the Entity Framework - is there any need use LINQ, does that add any value for me ?
I am about to create a Wniforms application.

best, i
 
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.
 
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.

Thanks for your thorough reply.
I am a programmer by training, worked with the Java platform since way back - so that is my point of reference.
So wrapping my head around the Microsoft Technology stack is a way for me to plan the work ahead.
Is there some good books/articles out there presenting the best-practices ?
I will be using the latest MSSQL-server, the it-dept. will upgrade the production database the coming week(s).

best, i
 
that is not really an answer to my question.
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.
 
Is there some good books/articles out there presenting the best-practices ?
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 use Equals() for comparisons when C#'s idiomatic use is to use the "==" operator.
 
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.
I kind of agree, although: Language-Integrated Query (LINQ) (C#)
Language-Integrated Query (LINQ) is the name for a set of technologies based on the integration of query capabilities directly into the C# language.
 
I am about to create a Wniforms application.
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.
does that add any value for me ?
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.

Do you need Linq code, if so, why? Do you understand the Linq syntax, well-enough to write a fully designed app?
Does your app have a database or an object orientated or file system based one, and if the answers are yes, then yes; you might want to consider Linq just on that basis. So do you require some form of database or object mapping, with file entities such as xml files etc?
that is not really an answer to my question.
Perhaps not; but it's still a valid point which I assume @Skydiver thought might have been confusing you.
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 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. :)
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.
 
Opinions differ John. I think people use the word "technology" to loosely now-a-days. I look at Linq as an extension to c sharp. Do you consider c sharp to be a technology too?

I would barely consider .Net to be a technology and c sharp to be a derivative language of .Net.
 
I look at Linq as an extension to c sharp.
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.
 
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 use Equals() for comparisons when C#'s idiomatic use is to use the "==" operator.

Thanks.
I am not really looking for transformation of the syntax, I am fine with that.
Rather when it comes to the 'Technology'-stack (using the term loosely here) .
In Java I would choose for instance : JEE, using an entity-framework (i.e 'Hibernate'-Framework ) + Wildfly as an Application Server and MySQL as my db.
- where hibernate has its Query-language (HQL). The Wildfly server is responsible for the connection to the MySQL-db (credentials etc are set there)

My hopes for a small Winforms-project , is to make it as-simple-as-possible and readable (we can call it a reference application).
- So, C#.NET , using the Entity-Framework with MSSQL. And if it makes sense to use LINQ, if LINQ makes the code more readable ....
So I would like to have some basic principles doing this (not cluttering up the codebase) , using this application with appropriate technologies to be able to convince my coworkers that we can use C#.NET for some of our applications.

best, i
this is a viable way into the future ...
 
If you are starting from scratch, don't get sucked it WinForms. Yes, it may look similar to other Java based GUI frameworks and feel more comfortable move, but WinForms is at End Of Life. It was originally just supposed to wither away in .NET Framework 4.x, but it got a little bit of extra life support by getting ported into .NET Core 3.1 to give companies more time to port their legacy LOB applications.
 
Back
Top Bottom