For further actions, you may consider blocking this person and/or reporting abuse
Read next
Sitecore PowerShell Script to delete unused items in the Media Library
Daniel Gomez -
How to Edit a PDF File in C# (Developer Tutorial)
Zeeshan Wazir -
C# dasturlash tilida ma'lumot turlari va ularning ustun hamda kamchiliklari
Jaloliddin -
Implementing Messaging in .NET: A Comprehensive Guide
Adrián Bailador -
Top comments (2)
The performance is sometimes less than stellar when it takes 2x time to run a query from cold start is kind of a big understatement.
A lot of developers prefer to use ADO.NET instead of EF Core, i am one of them, first you have better performance out of the box, more freedom when it comes to forging your queries.
But yeah, like restricting LINQ if you're not using EF core sounds like a dumb idea, but sometimes there is a reason for it.
A lot of developers ignore that
cannot actually be awaited as easy as a regular foreach, and stuff like that can cause issues, i really don't see that happening though with experienced developers but it does have the potential to introduce headaches.
Still not good enough reason to restrict it, but if you're not using EF Core, and it's the data layer, you're not trying to offload something from the database to the service (something like invoice computation) , i really don't see where you will actually need to use it.
I think a key thing to note here is the OP was talking about LINQ extension methods. That would include things like the IList or IEnumerable's
Where,Select, or other methods.I agree that the
.ForEachextension method is nearly always a bad idea performance wise, but unless you're really diving deep into performance, most of those extension methods are fine in moderation. I mean to say, if you're writing complex queries, that might be better served in the database with SPROCs or similar, but if we're talking about selecting into DTOs or filtering small amounts of data, those extension methods are fantastic.