LINQ to Entities
-
Until you've fully explored enough of the wrong ways, you'll never truly appreciate the right way. :-D
You missed the word "grasshopper" from the end of that sentence.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
And what do you think it's doing in the background?
musefan wrote:
it can save a lot of time
Coding time, yes. Maybe not execution time (have you benchmarked it?). Maybe not maintenance time if the next person to touch the code doesn't understand it. I'll stick with simpler code.
Good point. LINQ is usually slower when I've dabbled with it. And although more verbose I always prefer simple explicit code, less error prone, easier for others to understand and easier to debug.
Regards, Rob Philpott.
-
do you really use it ? why i need to learn new syntax to get lower performance ? when i have no time and the high performance is not a must i go for the Dataset. its ok with the collections and arrays but with the database !! what do you think ? regardless that i am late to ask this :D
I'm only just starting to learn LINQ: I have pretty reasonable SQL abilities already. The main reason I am learning it is that I feel that the stronger typing and compile time syntax checking available in LINQ to SQL has got to produce better, cleaner, more reliable solutions than hand crafted SQL. Once I've got a good feeling for it, I'll make the decision to either go with it or back - but until I have that level of confidence in my abilities with it, I can't make that call. If I don't learn LINQ, I made that call without sufficient information.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
-
do you really use it ? why i need to learn new syntax to get lower performance ? when i have no time and the high performance is not a must i go for the Dataset. its ok with the collections and arrays but with the database !! what do you think ? regardless that i am late to ask this :D
Perhaps you could look here for some information Entity Framework Performance[^]
I know the language. I've read a book. - _Madmatt
-
And what do you think it's doing in the background?
musefan wrote:
it can save a lot of time
Coding time, yes. Maybe not execution time (have you benchmarked it?). Maybe not maintenance time if the next person to touch the code doesn't understand it. I'll stick with simpler code.
PIEBALDconsult wrote:
have you benchmarked it?
Yes, I have. Entity Framework Performance[^]
I know the language. I've read a book. - _Madmatt
-
I'm only just starting to learn LINQ: I have pretty reasonable SQL abilities already. The main reason I am learning it is that I feel that the stronger typing and compile time syntax checking available in LINQ to SQL has got to produce better, cleaner, more reliable solutions than hand crafted SQL. Once I've got a good feeling for it, I'll make the decision to either go with it or back - but until I have that level of confidence in my abilities with it, I can't make that call. If I don't learn LINQ, I made that call without sufficient information.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
OriginalGriff wrote:
If I don't learn LINQ, I made that call without sufficient information.
Hear hear! I finally dabbled in a little bit of Linq (to SQL?) a few weeks ago. It gave me no benefit and I don't see how it can deliver any. Especially considering I use several different database systems, not just Sql Server.
OriginalGriff wrote:
LINQ to SQL has got to produce better, cleaner, more reliable solutions than hand crafted SQL.
Not if you've been hand crafting clean reliable SQL for twenty years. If Linq produces better SQL than you do, then go with it.
-
OriginalGriff wrote:
If I don't learn LINQ, I made that call without sufficient information.
Hear hear! I finally dabbled in a little bit of Linq (to SQL?) a few weeks ago. It gave me no benefit and I don't see how it can deliver any. Especially considering I use several different database systems, not just Sql Server.
OriginalGriff wrote:
LINQ to SQL has got to produce better, cleaner, more reliable solutions than hand crafted SQL.
Not if you've been hand crafting clean reliable SQL for twenty years. If Linq produces better SQL than you do, then go with it.
PIEBALDconsult wrote:
Not if you've been hand crafting clean reliable SQL for twenty years.
Not quite what I meant: I was thinking more that finger trouble with LINQ is more likely to cause a compilation error, where in SQL it is run time and so harder to test and detect.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
-
PIEBALDconsult wrote:
Not if you've been hand crafting clean reliable SQL for twenty years.
Not quite what I meant: I was thinking more that finger trouble with LINQ is more likely to cause a compilation error, where in SQL it is run time and so harder to test and detect.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
Oh, sure, but you can develop and test your more-complex SQL statements with another tool and then copy-and-paste them into your application. An additional benefit of that is that it drives parameter use rather than concatenation.
-
Oh, sure, but you can develop and test your more-complex SQL statements with another tool and then copy-and-paste them into your application. An additional benefit of that is that it drives parameter use rather than concatenation.
I would assume that Linq generates parametrized queries anyway: I always use them with SQL. :-D
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
-
I would assume that Linq generates parametrized queries anyway: I always use them with SQL. :-D
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
OriginalGriff wrote:
I always use them with SQL
Yes, but others don't, because concatenation is easier unless your framework (e.g. Linq) makes parameters easier.
-
OriginalGriff wrote:
I always use them with SQL
Yes, but others don't, because concatenation is easier unless your framework (e.g. Linq) makes parameters easier.
PIEBALDconsult wrote:
Yes, but others don't, because concatenation is easier they are lazy idiots who like leaving their DB wide open to an SQL injection attack
FTFY! :laugh:
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
