如何使用.NET在DynamoDB中查询数据

这种抽象方式带来的弊端在于，它会隐藏一些重要的细节：你无法清楚地了解在底层究竟有哪些数据被发送到了 DynamoDB 中，而这会使得调试和性能优化变得更加困难。

设置上下文环境

在创建数据库上下文时，有几种可供选择的方案：

选项 1 — 使用依赖注入：

// Program.cs
builder.Services.AddSingleton();
builderservices.AddSingleton(sp => {
    var client = sp.GetRequiredService();
    return new DynamoDBContext(client);
});

// 在仓库或服务层中，注入 IDynamoDBContext
public class OrderRepository
{
    private readonly IDynamoDBContext _context;

    public OrderRepository(IDynamoDBContext context)
    {
        _context = context;
    }
}

选项 2 — 仅注册 AmazonDynamoDBClient，并在每次操作时重新创建上下文对象：

// Program.cs
builder.Services.AddSingleton();

相应的实现代码如下：

public class OrderRepository
{
    private readonly IAmazonDynamoDB _client;

    public OrderRepository(IAmazonDynamoDB client)
    {
        _client = client;
    }

    public async Task> GetOrdersAsync(string customerId)
    {
        var context = new DynamoDBContext(_client); // 创建上下文对象非常简单
        return await context.QueryAsync(customerId).GetRemainingAsync();
    }
}

哪一种方案更好呢？选项 1 更简洁，也更容易进行单元测试——因为在单元测试中可以轻松地模拟 IDynamoDBContext 对象。选项 2 也是可行的，因为创建 DynamoDBContext 对象的成本较低，但这样一来就无法方便地对它进行模拟了。

何时应该使用对象持久化技术？对于大多数 .NET 应用程序来说，这是一种推荐的做法。这种技术代码结构清晰、类型安全，并且能够自然地融入现有的 C# 代码库中。

从 C# 中查询多属性 GSI

在编写本文时，DynamoDBContext.QueryAsync 这个便捷的重载方法并不直接支持多属性 GSI 的键条件设置——你需要使用低级别的客户端接口 (IAmazonDynamoDB) 并传入一个 KeyConditionExpression 对象。不过，将查询结果反序列化为对应的类型化模型仍然非常简单。

以下是一个示例：这个查询针对的是一个 GSI，该 GSI 的复合分区键为 (customerId, status)，排序键为 createdAt，因此它能够返回自指定日期以来该客户的所有未完成订单信息：

public async Task> GetOrdersByStatusSinceAsync(
string customerId,
string status,
long fromDate)
{
var request = new QueryRequest
{
TableName = "Orders",
IndexName = "customerStatus-createdAt-index",
KeyConditionExpression =
"customerId = :CustomerId " +
"AND #status = :status " + // 使用 "#status" 是因为 "status" 是一个保留字
"AND createdAt > :fromDate",
ExpressionAttributeNames = new Dictionary
{
{ "#status", "status" }
},
ExpressionAttributeValues = new Dictionary
{
{ ":customerId", new AttributeValue { S = customerId } },
{ ":status", new AttributeValue { S = status } },
{ ":fromDate", new AttributeValue { N = fromDate.ToString() } }
},
ScanIndexForward = false // 由于排序键是时间戳，因此需要反向排序
};

// 使用 DynamoDBContext 将查询结果手动反序列化为 OrderDto 对象列表
return _context.FromDocuments(response.Items.Select(Document.FromAttributeMap)).ToList();
}


观察上面的代码，请注意以下几点：

• 两个分区键属性（customerId和status）都使用了“等于”关系进行匹配——这是必须的。

• 排序键（createdAt）使用了“大于”关系作为匹配条件，这也是允许的。

• 没有使用任何合成字符串，也没有采用脆弱的格式化方式，更没有对现有记录进行补录操作。

如果你正在使用包含合成键的现有代码库，那么考虑是否将系统迁移到多属性GSI模型是很有意义的。以前导致迁移过程变得繁琐的补录问题已经不存在了，因为DynamoDb的多属性GSI模型能够自动处理这类问题。

查询与扫描

在使用DynamoDB时，理解这一概念至关重要——同时，这也是导致性能问题和成本问题的常见原因之一。

查询

Query操作会利用分区键来检索数据，并且还可以通过排序键进一步筛选结果。DynamoDB能够准确判断应该查找哪个分区，仅读取相关的数据，并高效地返回结果。

// 获取某位客户的所有订单
var orders = await _context
    .QueryAsync：>("customer-123")
    .GetRemainingAsync();

你还可以通过排序键条件来进一步缩小搜索范围——例如，只获取过去30天内下达的订单：

var thirtyDaysAgo = DateTimeOffset.UtcNow.AddDays(-30).ToUnixTimeMilliseconds();

var orders = await _context.QueryAsync(
    "customer-123",
    QueryOperator.GreaterThan,
    new List