Maybe you should have digged a little further. To lazy load related entities you would have to declare the navigational properties virtual.
https://docs.microsoft.com/en-us/ef/ef6/fundamentals/proxies
Note that the EF will not create proxies for types where there is nothing for the proxy to do.
This means that you can also avoid proxies by having types that are sealed and/or
have no virtual properties.</quote>
Entity Framework is an absolutely top-tier ORM (if you like ORMs). Because lazy loading is frowned upon by some purists (and DBAs), EF also support controlled/eager loading where nothing happens (lazily) behind the scene.
You can - for instance - in the query use <code>.Include(x => x.RelatedEntity)</code> to load a related entity eagerly without going back to the database server to load the related entity for each row (the so-called N+1 problem).
So why would the state of the product as it was 10 years ago matter in your decision to switch back today?
Working with Microsoft tech felt like being gaslighted by an abusive partner. Their documentation absolutely did not match what their tech actually did.
I'm really happy working in Go on Linux. Why would I want to switch back?
Just because there are some unintuitive edge cases which you can identify in a technology doesn't mean the technology is "wrong". Pick your favourite technology and I am sure you can find many such unintuitive edge cases if you purposefully look for them.
They took ages to for them to finally update the pages. In fact it took a well known consultant, one of their mvps, writing not just documentation that worked, but also thorough instructions on how to fix the predicament Microsoft got you in. I wouldn’t be surprised if the team writing the docs were completely lost until they read his blog. The service was just one component but it was ridiculously complex for what it did. Sometimes I wonder if they crammed the service (Forefront Identity Manager) in to save the team working on it since they cancelled the standalone version of it.
Their docs can be good and are certainly improving but it does still feel like disjointed teams doing their own thing sometimes.
There is seldom any product from them that feels consistent and cohesive in its design and in the ways in which you can interact with it.
I would agree they’re usually good but when they were bad, they were real bad. And bad seemed to happen a lot more outside of the “big” internal fiefdoms at the time (Desktop, Server, AD, Exchange, etc.).
They did seem to hit a rough patch during the transition but the only thing I’ve seen is gaps here and there due to what I assume is incongruity between teams. Like tools being moved from an installer and therefore the installer docs but corresponding docs for how to get those tools not being created/updated elsewhere.
Unfortunately the legacy tooling is infuriating to work with. It's been steadily improving for the past few years with the advent of .NET Core but in practice this doesn't mean much. If you work at a ".NET shop" then odds are that the devs that work there have been firing up Visual Studio and creating solution files for the better part of two decades; good luck getting them to use dotnet or Docker Compose, not to mention the long-lived legacy apps floating around that are still built that way and live on IIS in a corporate datacenter someplace.
You kind of just described Linux, Unix, modern Web dev, iOS dev, Android dev etc.
If you search for a Linux problem, you'll get 50 different people telling you 25 different ways of fixing it, most of which work.
If you search for a Microsoft problem, you'll get 50 pages of corporate bullshit that pretend everything's OK. You have to ignore those and dig further to find some unofficial blogger or random dev post that actually tells you something useful.
Also looking at you, Apple - less bullshit and more honesty in your support pages please
Not in my experience. They may have worked for some version of some distro, but it is almost always not the one I'm trying to fix the problem on.
> If you search for a Microsoft problem, you'll get 50 pages of corporate bullshit that pretend everything's OK. You have to ignore those and dig further to find some unofficial blogger or random dev post that actually tells you something useful.
Unfortunately that is also pretty accurate, and it has been getting worse since Windows 10, resembling more and more the problem with searching for solutions to Linux issues. Does this fix still work for 1901 or did it only work for 1607?
Add Android on this category too. They also do videos to be even more infuriating!
More devs seem to have this opinion of Microsoft technologies though. Their desktop OS is the most dreaded as a platform, and the most dreaded of any OS except for Android (by 4‰, and of course devs already killed Windows Mobile)¹. And even more relevant to the link we’re discussing, another relatively low-barrier-to-entry language they created is the single most-hated programming language there is².
¹https://insights.stackoverflow.com/survey/2020#technology-mo... ²https://insights.stackoverflow.com/survey/2020#technology-mo...
If you're trying to lazy load after that, you will get significant performance issues.
Otherwise, I've created an erp+e-commerce on EF and didn't encounter much issues.
One time, i had an performance issue case and detailed the issue on the nuget repo. Next release had a workaround.
I just use SQL these days. Way better. More boilerplate, but that's not a bad thing.
Which I would totally have understood and forgiven if they'd been honest about it. But all the documentation was lying, except this one tiny bit buried deep in the tech docs. That wasn't the first time I've encountered this phenomenon in Microsoft tech. It seems there's a mis-communication between the documentation team and the actual dev team, and they end up documenting what should happen instead of what actually happens.
You said yourself that the lazy loading actually did work most of the time except for these problem cases, right?
So doesn't that sound more like it might just be an unintentional bug or maybe you had your environment configured differently from what the docs were expecting?
It really sounds to me like you threw the baby out with the bathwater over a small bug, when bugs of a similar magnitude will likely be present on every other platform too (including documentation bugs)
I've never used EF or developed business apps in .NET, but I have used similar technologies like Hibernate in Java and I think you are basically describing standard caveats with any ORM. Lazy loading is often a non-obvious behavior.
If your documentation says in several places that your system does X, but it doesn't, it does Y, then that's lies.
It might be caused by a bug, and what you're documenting is intended behaviour not actual behaviour. But then you need to say that somewhere - something like "We expect the system to do X but we haven't actually tested it so it might not". Not saying that, and instead saying "the system does X" is lying.
And yeah, I stopped using ORMs too :) They just get in the way.
As others have said, it's a problem that's particularly apparent with Microsoft - it feels disjointed. Like the documentation team read a different spec than the development team.
I was not having the best time mental-health-wise anyway about 10 years ago. I was freelancing and writing an application for a doctor's surgery in C#, using some of the cool new toys they'd produced for it. Including Entity Framework. Which came with lazy loading of object properties, cool. Except I kept bumping into cases where the object hadn't lazy-loaded, and data I knew should be there, wasn't. Digging in through myriad stacks of documentation and notes, all of which said that data would be loaded if it was asked for without needing to load it, I finally bump into a small note, obviously written by an actual dev, that cheerfully pointed out something like "to ensure your data is actually loaded into the object, you'll need to call the loadData() method before using it" (I paraphrase from memory).
I lost it. I completed that project, then uninstalled Windows, installed Ubuntu, and started learning Go (I intended to also learn Rails and Python, but fell in love with Go's simplicity and haven't moved on since).
It actually helped with my mental health. Realising that at least part of my problem was that people were professionally lying to me was an insight I needed.
I'm never trusting a Microsoft technology again. It's always nice and slick on the surface, and then a twisting pile of mess underneath.