> since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource
If you have to troubleshoot software advertised and explained by happy smilling people dragging and dropping things, code automagically appearing from snippets, claiming that "it's easy" - RUN AWAY. Your mental health is at stake.
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.
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.
What an abysmal way of developing applications. Everything (containers, widgets, etc.) is basically SVG's and your application looks like your designers couldn't use anything but MS Paint. Creating more complicated interactions with buttons and other UI elements was a pain to develop and making the UI responsive was a nightmare. The generated HTML was insanely ugly and the application was very slow/sluggish feeling. After fighting for a couple weeks, I began to (behind the scenes) build out a quick web application alternative to pitch. Long story short, he LOVED the web app version and that is what we are still using today company wide.
Controversial opinion: vector-based UI widgets are the right way to do web apps. Instead of all the existing framework approaches that ultimately produce HTML, both developers and users would be better served by using HTML for the elements on a screen that correspond to documents, but the web app's "chrome" should use SVG. Most of the complications of frameworks come from a blind spot on the part of developers, who continually select a tool with a high impedance mismatch to their goal (producing an app). This blind spot on the part of developers leaves this area under-explored, and in turn there's under-investment in the specs / on the part of browser makers to eliminate pain points in the way that developers are actually using the platform for their work.
I agree with you in principle that SVG is a better match to app UIs, but we'd need a good layout story for that to happen. And I'm using SVG for much of my own application interface!
I love the idea of punting on HTML and writing a ground-up SVG UI toolkit, or even a WebGL based on if you're feeling ambitious, but giving up on the built-in browser behavior and all of the automation tooling around interacting with HTML is a non-starter for most use cases.
- Canvas apps: worth it only for very simple applications that interact with another MS datastore (Sharepoint, CDS/Dataverse) and services. If you mostly need to interact with custom APIs, a simple custom webapp is probably a safer choice.
- Power Automate: stick to very simple flows, take advantage of the connectors but avoid at all cost complex business logic within the flow itself
- Model-driven apps: more interesting in my opinion. They effectively are mini-instances of Dynamics CRM, and you get A LOT of functionality out of the box. You can't tune the UI much, but you get the benefit to build an "interactive database" very quickly, with support for RBAC system, OData REST APIs, Views, Workflows, C# plugins, dashboards. If you need an internal application, used only by a few people (licensing), where you need an interactive data-store without complex requirements on business logic and custom UIs, then I think Model-driven apps can be terribly effective. Now, if only the licensing wasn't so damn complicated...
I've seen those projects where I'm brought in to fix some internal project gone wrong because they took internal softdev with no knowledge of a platform that exist for more than 15 years.
Meanwhile, I shipped whole systems in half the time you took to "roll your own".
Just try to roll your own ERP/CRM, we saw plenty of time how that goes.
Or go directly into this module: https://docs.microsoft.com/en-us/learn/paths/integrate-power...
Pretty much this. Use MS Power platform exclusively for reading/writing from MS things and you should be OK. Venture beyond that and it's painful.
A lot of stuff seems to have grown out of (or is just layered upon) Sharepoint and Dynamics, so there is a lot of synergy there.
Through Edge browser. Corporations think "it's secure" to lock stuff to work in one browser and MS is more than happy to deliver this.
My favourite one is a bug in Flow where you paste a string and the entire UI goes in to an error state (can't even save) so you have to reload and lose any existing changes.
We have a handful of PowerApps at our company and they’re really just forms hosted on Sharepoint sites. Type in some info, select some drop downs and hit enter. I still haven’t experienced PowerApps from the development side, but I’ve been pretty unimpressed with the work I’ve seen from it.
Maybe just a few of the "over a dozen" to give the rest of us a sense of the sort of apps that can be successfully created in this environment.
Was there anything that was less-than-perfect particular from the perspective of the end-user?
Has your company decide to use powerapps for all CRUD requirements going forward? This seems logical based on your assessment.
It sounds like your app was not so simple.
We wanted it to be able to integrate with our backend which lives outside the MS ecosystem. No problem we thought - that's what custom connectors are for. Except they don't work with any of the automated form generation functionality. So we pretty much have to build the form entirely manually.
Low code becomes high code all of a sudden - except it's worse than just coding and learning a new framework. You can't just input your code anywhere you want, or import your dependencies, etc... You have to hunt around in a zillion different (laggy as all hell) interfaces to find the right location where that code can live. Or maybe it's not code - but a toggle somewhere... OMG... kill me.
Good luck if you are trying to learn the lower level aspects... since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource - and that your connector actually works as advertised.
If you can code - and your stack doesn't already entirely consist of the MS ecosystem. Just roll your own.