Folks, I spent Sunday afternoon playing around with SQL Server Graph
databases, and as I expected, it all works as advertised. It's pretty neat
and the query syntax is comprehensible to mortals, unlike my experiments
with Cosmos DB and the Gremlin API which is as cryptic as abstract algebra.
So
Hi Greg,
We try to get devs to avoid using EF in anger at all, let alone for use with
Graph in SQL Server.
It's also not just EF support that's needed when new datatypes appear, client
libraries, etc have to be updated too. Anyone using EF is always well behind in
ability to use current
Dr L,
Very interesting! What do you recommend .NET developers to use when talking
to SQL Server? Another ORM? Plain 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
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
