It's a Tuesday afternoon and you're debugging a feature that touches four different pieces of data. First, you write a SQL query to pull a customer record from the database. Then you filter an in-memory list of orders using LINQ. Then you parse a JSON payload from a third-party API, reaching for dot-notation and the occasional JSONPath expression. Finally, you open a legacy XML configuration file and, out of muscle memory, write an XPath query to find the node you need.

We Are .NET

A conceptual overview of how .NET developers routinely switch between multiple data query languages — SQL, LINQ, XPath, JSONPath, GraphQL — because each data format (relational tables, XML trees, JSON documents, graphs, in-memory objects) has fundamentally different operations that naturally give rise to their own query dialect. The post traces .NET's history from flat files and ADO.NET through the XML decade, the JSON shift, NoSQL document stores, and graph databases, framing LINQ as Microsoft's ambitious but imperfect attempt to unify these dialects under one syntax. It sets up a multi-part series: Part 2 will cover concrete .NET code per format, and Part 3 will examine LINQ's abstraction limits, including emerging vector database formats.

The Many Languages of Data: How .NET Learned to Speak in Formats

Format vs. Language: Two Different Things

<p>LINQ works best when the familiar API still leaves each format’s rough edges visible.</p>
