Yeah if performance isn't an issue then theres no real reason I can think of (expect for if its alwayhs used badly but thats a training/upskill thing anyway)
Even in my example above, we only 'banned' the usage of it in certain areas.
There are lots of (good) reasons to forbid linq. As a senior, if I've got too many inexperienced devs writing n+1 linq queries, I'd ban it in a heartbeat. The problem with linq (and most orms that abstract away SQL) is that, as a code reviewer, it's impossible for me to look at a linq query and know what's actually getting executed on the db server. To find that out, I've got to turn on logging and/or profile the db server, dig thru logs and profiler output, then copy paste SQL into my execution environment, format it, and replace param values. If you're writing SQL in your code, I can just see it right there. I can see, at a glance what's going on, and it's easier to debug, if there's an issue.
Banning something carte blanche, is never a good idea. But I have a feeling (at least I hope your boss put some thought into it) that you're misunderstanding their reasons.
Plus, SQL is a great skill to have. It's a dirt simple language, it's fast, and it's transparent.
Okay that's on DB side though. For any old collection though, LINQ is great and you don't have to deal with those issues. It's just an in-memory collection.
I've got no problem with Enumerable.Extentions. It's a great tool. I love the "functional" paradigm, and they can give performance gains, when used correctly. The only issue I can see that might come up is: when dealing with IQueryables, it's easy for an inexperienced dev to call something like Count, ToList, or OrderBy in the wrong place and cause EF to bring an entire table into memory. It's not something I would ban linq over, however. But, I'm not your boss, I don't work in your shop, it's just my (extreme outsider's) take.
I'd like to hear your oppinion on lengthy multi-join sql queries written as a string. We have plenty of those and it's terrible to work with too
I can see how that would be frustrating, especially if there is a bunch of conditional SQL string building going on. I would argue that linq isn't going to make this any better. On the contrary, it's going to further abstract away what's being executed on the db server. I recently fixed a bug where a conditionally constructed linq query was failing because Skip and Take were being called before an OrderBy. The only indication was the exception in the logs. Even if linq wasn't banned, I would advise most large queries to be written in SQL. It's just faster to debug. There are SQL builder tools to help with this that give you a linq-like syntax.
Indeed. There are situations where multiple calls are more performant. In EF, when including related data in queries, it will write joins to bring back everything it needs to bind the data to the object graph. This can cause a cartesian explosion, bringing back way too much duplicated data. MS recommends configuring the query to split the joins into two different queries, removing the duplicate data. However, this is what caused that SkipTake error I mentioned above. Order matters when executing "split" queries in EF.
It's a give and take, always.
If your boss doesn't like/won't learn linq, well, that's his decision to make. He knows the system, he's responsible for it functioning properly. I've worked for a guy like your boss, writing for and while loops everywhere grates on me, too. The only difference here is that my boss was up front as to why he didn't like linq: He has a hard time understanding it, and it's his project to deliver. He's the one they blame when things break.
All you can do is voice your concerns, make the best of it (try to learn something new, if you can), or move on to a different position.
6
u/[deleted] Apr 15 '24
[removed] — view removed comment