Personal preference? Just code-gen appropriate ADO.NET code. A common problem with most ORMs is that the people coding them often make decisions that are not in your interest. At least when you do some code-gen, you can fix it if you don't like it.
Here's one simple example: when I used to teach ADO.NET, I'd always tell developers to NEVER use the AddWithValue() method on the Parameters collection of the SqlCommand object. Which method did they use in LINQ/EF? You guessed it, that one. And when you then have issues, how exactly do you fix them, when it's baked into the framework? These things are never an issue with toy apps, but they matter in anything that needs to scale. Any using any ORM will put you behind in the ability to use modern features of the DBs. For example, I'm already writing production-bound code today, that uses a feature added to Azure SQL DB yesterday and it will have a profoundly positive impact on the performance of the client's system. I don't want to be stuck in several years' time, wondering if they'll add support to my ORM for the new features. Graph was added to SQL Server in 2017. It's now the end of 2021. Why exactly isn't it in EF? But I also still have a strong preference for putting DB logic in stored procs rather than auto-generated on the fly in the app, for more reasons than I can go into here. But if you don't do that, you generally end up with intensely "chatty" applications that have no place in a cloud-first world. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile SQL Down Under | Web: https://sqldownunder.com<https://sqldownunder.com/> |About me: https://greglow.me From: ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> On Behalf Of Greg Keogh Sent: Tuesday, 26 October 2021 9:44 AM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: Re: SQL Graph databases Dr L, Very interesting! What do you recommend .NET developers to use when talking to SQL Server? Another ORM? Plain ADO.NET<http://ADO.NET>? Stored procs? Using an ORM does keep you at arms length from the DB engine and it abstracts away differences, but that's a good thing! I've never suffered from anything lagging behind SQL Server's current features before, but I guess it finally happened with Graph. So SQL Graph will go the way of Silverlight, WF, WCF, Cardspace and UWP. I can understand they published a Graph DB feature to be competitive, but you can't make people like it. I personally love Graph DBs, so I was keen to have one out-of-the-box, sort of. Greg K
