Certainly, but that's not the issue here, at least not to me. My gripe is with the hypothesized IEnumerable abuse breaking stuff one may reasonably expect to work, which goes against the principle of least surprise and as such would be a very bad idea in a public library or API of some sort. Or in short: don't do it (unless you're just fooling around).
Posts made by donk
-
RE: 𝄯 Sharp Regrets: Top 10 Worst C# Features
-
RE: 𝄯 Sharp Regrets: Top 10 Worst C# Features
Hyperbole etc.
ToList is an obvious problem, but I also can't imagine Sum, Min, Max, All, Aggregate, Average, Distinct, Count, Last, OrderBy et al working very well at all if the enumeration doesn't terminate.
-
RE: 𝄯 Sharp Regrets: Top 10 Worst C# Features
You'd break a lot of things by abusing IEnumerable for cyclic structures. Such as every goddamn extension method available. So by all means, you may fool around with it on your spare time for lulz, but write something like that in production code and I'd shoot you in the face.
-
RE: When Toddlers Program
You'd get fucking fired for writing comments like that here.
(Well, in my dreams at least. Though we do have a guideline that sort of says "don't write comments that are shit".)
-
RE: Do complex queries belong in business layer, or data layer?
There is, thankfully, tooling for that. Admittedly ass-backwards approach (not so much "code first" anymore eh), but whatcha gonna do?
(How about not using EF in the first place? Yeah, there's that...)
-
RE: Do complex queries belong in business layer, or data layer?
It's fine if the DB is subservient to the application (e.g., it's just acting as a persistent data store) and saves a bunch of typing. If it's the other way round, which happens any time the DB is shared between apps, then You Don't Want Code First.
How does code first save a bunch of typing?
I'd argue that a code-first model actually is easier to maintain as the database grows (i.e. is of non-trivial size). The usability of the visual edmx editor leaves a lot to be desired (not to mention editing the raw edmx file itself ), whereas you have complete control if you write your own classes and specify your own mapping.
Though it's often a headache to create a good code-first model from an existing database (again, of non-trivial size), even with the available tooling, we've been ditching the edmx file and converted to code first in a couple of bigger projects since it (at least for us) will pay off in the long run. (And since only code first is supported in EF7...)
IMO, YMMV etc. And both approaches suck in their own respective ways.
-
RE: Do complex queries belong in business layer, or data layer?
I suppose this separation into distinct BL and DAL subprojects is enforced by the company?
To me this kind of repository shenanigans is just cumbersome/overengineering. EF itself is your DAL. As long as you don't leak EF types from your BL I don't see any reason why the BL couldn't query EF directly.
Maybe I'm not seeing the whole picture, and I know I'm not helping, but I personally like to keep things as simple as possible...
-
RE: Why nested loop?
Had the same issue with SQL Server, that a big delete with a join on a temporary table took a long time to execute. What helped me was using the TABLOCKX hint in the delete statement to exclusively lock the table while deleting, i.e.
DELETE t FROM SomeTable t WITH (TABLOCKX) JOIN #tempTable o ON o.Id = t.Id
It made a huge impact, like from > 1 minute to < 1 second. I'd presume Postgres has some similar locking hint you can use? LOCK TABLE items IN EXCLUSIVE MODE?