Cẩm nang thực địa về các định dạng dữ liệu .NET

Trong Phần 1, chúng ta đã lập luận rằng mỗi định dạng dữ liệu đều phát triển ngôn ngữ riêng của nó vì hình dạng dữ liệu quyết định loại điều hướng nào có ý nghĩa. Phần này là tham chiếu mà bạn thực sự đánh dấu trang: một chuyến đi qua các định dạng mà nhà phát triển .NET thường gặp, ngôn ngữ gốc mà mỗi định dạng sử dụng, và một đoạn mã điển hình nhỏ cho mỗi định dạng để bạn có thể thấy hình dạng của mã nguồn, không chỉ lý thuyết.

Hãy coi đây là cẩm nang thực địa, không phải hướng dẫn — đủ để nhận ra phương ngữ của mỗi định dạng và biết nơi cần tìm tiếp theo.

CSV và văn bản phân tách

Ngôn ngữ gốc: không thực sự — chỉ là các quy tắc phân tích chuỗi,尽管 CsvHelper đã trở thành gần như một DSL thực tế để ánh xạ các hàng sang kiểu dữ liệu.

CSV là định dạng cũ nhất, ít cấu trúc nhất trong danh sách này. Không có ngôn ngữ truy vấn vì gần như không có schema — chỉ có các hàng và ký hiệu phân tách. Trong .NET hiện đại, CsvHelper là thư viện tiêu chuẩn, xử lý việc trích dẫn, thoát ký tự và ánh xạ kiểu dữ liệu mà mã String.Split thủ công thường mắc lỗi nhiều hơn mọi người tưởng.

using CsvHelper;
using System.Globalization;

using var reader = new StreamReader("orders.csv");
using var csv = new CsvReader(reader, CultureInfo.InvariantCulture);

var orders = csv.GetRecords<Order>()
    .Where(o => o.Total > 100)
    .ToList();

Lưu ý rằng một khi CSV được phân tích thành các đối tượng Order, “việc truy vấn” chỉ là LINQ to Objects. Ngôn ngữ gốc của CSV thực sự chỉ là phân tích — việc truy vấn xảy ra sau khi chuyển đổi sang định dạng khác.

Sử dụng khi: bạn đang xử lý các tệp xuất, nhập hoặc nhật ký dữ liệu tự nhiên dạng bảng và không cần quan hệ giữa các bản ghi.

RDBMS: Ngôn ngữ truy vấn gốc

Ngôn ngữ gốc: SQL.

Cơ sở dữ liệu quan hệ là định dạng mà hầu hết nhà phát triển .NET gặp đầu tiên, và SQL là ngôn ngữ trưởng thành và biểu cảm nhất trong toàn bộ danh sách này. .NET có ba cách phổ biến để sử dụng nó, ở các mức trừu tượng hóa tăng dần:

// Raw ADO.NET — closest to the metal
using var connection = new SqlConnection(connectionString);
using var command = new SqlCommand(
    "SELECT * FROM Orders WHERE Total > @minTotal",
    connection);
command.Parameters.AddWithValue("@minTotal", 100);
connection.Open();
using var reader = command.ExecuteReader();

// Dapper — a thin, popular micro-ORM
var orders = connection.Query<Order>(
    "SELECT * FROM Orders WHERE Total > @minTotal",
    new { minTotal = 100 });

// Entity Framework Core — LINQ translated to SQL
var orders = dbContext.Orders
    .Where(o => o.Total > 100)
    .ToList();

Ví dụ EF Core đáng để suy nghĩ: bạn viết LINQ, nhưng bên dưới, nó được biên dịch thành SQL và gửi đến cơ sở dữ liệu. Đây là mô hình nhà cung cấp LINQ đang hoạt động — cùng cú pháp, được dịch sang ngôn ngữ gốc của định dạng. Điều này tiện lợi, nhưng đây cũng là nơi đầu tiên nhà phát triển gặp vấn đề “abstraction leak” mà loạt bài này sẽ quay lại ở Phần 3 — một số biểu thức LINQ không dịch sạch sẽ, và SQL được tạo ra không phải lúc nào cũng là thứ bạn viết bằng tay.

Sử dụng khi: dữ liệu của bạn có quan hệ mạnh mẽ, cần tính toàn vẹn giao dịch, hoặc được hưởng lợi từ các hoạt động tập hợp như JOIN và tổng hợp.

XML: Định dạng cây

Ngôn ngữ gốc: XPath, XQuery, và trong .NET, LINQ to XML.

Dữ liệu XML là một cây, vì vậy các ngôn ngữ của nó được xây dựng xung quanh việc duyệt — đi sâu vào các nút con, khớp theo đường dẫn, lọc theo thuộc tính.

using System.Xml.Linq;

XDocument doc = XDocument.Load("catalog.xml");

// LINQ to XML — tree traversal expressed as LINQ
var fictionBooks = doc.Descendants("book")
    .Where(b => (string)b.Attribute("category") == "fiction")
    .Select(b => (string)b.Element("title"));

// Equivalent XPath, for comparison
var xpathResult = doc.XPathSelectElements(
    "//book[@category='fiction']/title");

Cả hai đoạn mã đều làm cùng một việc, nhưng chúng đọc khác nhau — LINQ to XML cảm giác như truy vấn một collection, trong khi XPath cảm giác như đưa hướng dẫn qua một cây. Điều này không phải tình cờ: XPath được xây dựng purpose-built cho việc duyệt cây, và LINQ to XML là một wrapper sau này, mang tính C# hơn, bao quanh cùng việc duyệt cơ bản.

Sử dụng khi: bạn đang làm việc với các tệp cấu hình, dịch vụ SOAP, các định dạng trao đổi tài liệu (như Office Open XML), hoặc bất cứ thứ gì có schema chặt chẽ, có thể kiểm chứng (XSD).

JSON: Ngôn ngữ chung của Web

Ngôn ngữ gốc: không có tiêu chuẩn hình thức duy nhất, mà là sự kết hợp giữa deserialization mạnh kiểu, truy cập động, và JSONPath cho các truy vấn ad hoc.

JSON vượt qua XML cho các payload API vì nó nhẹ hơn và ánh xạ tự nhiên sang các đối tượng JavaScript. Mối quan hệ của .NET với JSON đã đi qua Newtonsoft.Json (Json.NET) đến System.Text.Json tích hợp sẵn.

using System.Text.Json;

string json = await httpClient.GetStringAsync(
    "https://api.example.com/orders");

// Strongly-typed — the common case
var orders = JsonSerializer.Deserialize<List<Order>>(json);
var bigOrders = orders.Where(o => o.Total > 100);

// Loosely-typed — when the shape isn't known ahead of time
using JsonDocument doc = JsonDocument.Parse(json);
JsonElement root = doc.RootElement;
foreach (var order in root.EnumerateArray())
{
    if (order.GetProperty("total").GetDouble() > 100)
    {
        Console.WriteLine(order.GetProperty("id").GetString());
    }
}

Khi JSON được deserialized thành các đối tượng, “ngôn ngữ” bạn sử dụng lại là LINQ to Objects — cùng mô hình chúng ta thấy với CSV. Đặc điểm riêng của JSON là nó đứng ở hai thế giới: deserialization mạnh kiểu, cứng nhắc khi bạn kiểm soát cả hai đầu, và điều hướng lỏng lẻo, dựa trên đường dẫn (JsonDocument, hoặc các thư viện JSONPath) khi bạn đang xử lý tài liệu có hình dạng bạn không kiểm soát hoàn toàn.

Sử dụng khi: bạn đang xây dựng hoặc sử dụng các HTTP API, hoặc lưu trữ dữ liệu bán cấu trúc nơi schema cứng nhắc nhiều hơn rắc rối.

Cơ sở dữ liệu tài liệu: Môi trường sống gốc của JSON

Ngôn ngữ gốc: các phương ngữ giống SQL được xây dựng purpose-built cho tài liệu JSON — SQL API của Cosmos DB, ngôn ngữ truy vấn của MongoDB.

Cơ sở dữ liệu tài liệu lưu trữ các tài liệu hình dạng JSON nhưng truy vấn chúng bằng thứ gì đó trông giống SQL — một lựa chọn thiết kế có ý thức để ngôn ngữ dễ tiếp cận, dù mô hình bên dưới không phải quan hệ.

using Microsoft.Azure.Cosmos;

Container container = client.GetContainer("SalesDb", "Orders");

var query = new QueryDefinition(
    "SELECT * FROM o WHERE o.total > @minTotal")
    .WithParameter("@minTotal", 100);

using FeedIterator<Order> iterator = container.GetItemQueryIterator<Order>(query);
while (iterator.HasMoreResults)
{
    FeedResponse<Order> response = await iterator.ReadNextAsync();
    foreach (var order in response) { /* ... */ }
}

Đây là minh họa tốt về mối quan hệ định dạng-ngôn ngữ trở nên mờ đi có chủ đích: ngôn ngữ truy vấn của Cosmos DB mượn cú pháp SQL để dễ quen thuộc, nhưng nó hoạt động trên các tài liệu JSON, không phải các hàng quan hệ — không có JOIN giữa các container, hành vi đánh dấu index khác, mô hình chi phí khác. Từ vựng được mượn; ngữ pháp bên dưới không giống nhau.

Sử dụng khi: dữ liệu của bạn tự nhiên hình tài liệu, schema của bạn phát triển thường xuyên, hoặc bạn cần quy mô ngang mà RDBMS truyền thống làm đắt đỏ.

Dữ liệu đồ thị: Quan hệ như công dân hạng nhất

Ngôn ngữ gốc: GraphQL (cho việc truy vấn API), Cypher/Gremlin (cho cơ sở dữ liệu đồ thị).

Đồ thị là định dạng mà các quan hệ giữa các bản ghi quan trọng như chính các bản ghi — mạng xã hội, hệ thống gợi ý, phát hiện gian lận. Trong .NET, hỗ trợ GraphQL thường đến qua thư viện như HotChocolate, xuất một schema mà khách hàng truy vấn bằng cú pháp riêng của GraphQL:

query {
  order(id: "1001") {
    id
    total
    customer {
      name
      previousOrders(last: 5) {
        total
      }
    }
  }
}

// Protobuf — schema-defined, then generated C# classes
Order order = Order.Parser.ParseFrom(binaryData);

// From here, it's just an object again
if (order.Total > 100) { /* ... */ }

var bigRecentOrders = orders
    .Where(o => o.Total > 100 && o.Date > DateTime.Now.AddDays(-30))
    .OrderByDescending(o => o.Total)
    .Select(o => new { o.Id, o.Total });