三层架构下C#跨服务共享数据访问的解耦实现方案咨询

看起来你已经踩对了Clean Code的核心方向——先统计订单ID频次，再映射菜单名称，而不是直接关联两张表，这个思路完美契合分离关注点的原则！接下来我们可以把这个逻辑拆解得更优雅，同时解决复用、解耦和避免重复查询的问题，我结合之前做类似餐饮系统的经验给你梳理下具体方案：

先明确各层的核心职责（避免越界） #

在三层架构里，每个层的边界要清晰，绝对不能越界：

• 仓储层：只负责数据的CRUD操作，不要包含任何业务逻辑，对外暴露抽象接口，应用层依赖接口而非具体实现。
• 应用层：负责业务逻辑的编排，将仓储层的数据组合成业务需要的结果，但不要直接操作数据库或跨实体强耦合。
• 领域层（可选）：如果你的项目有这一层，核心实体（比如Customer、MenuOptions）应该放在这里，定义实体的核心规则。

分步重构实现方案 #

1. 抽象仓储层，解除应用层对数据实体的直接依赖 #

首先，我们需要给Customer和MenuOptions分别定义仓储接口，让应用层通过接口获取数据，而不是像你原来那样直接传List<Customer>（这种方式不符合依赖倒置，也不利于后续扩展）：

// 通用仓储接口（可放在Core/Contracts项目，供所有仓储实现复用）
public interface IRepository<T> where T : class
{
    Task<IEnumerable<T>> GetAllAsync(CancellationToken cancellationToken = default);
}

// 客户仓储的特定接口，可添加业务相关的查询方法
public interface ICustomerRepository : IRepository<Customer>
{
    // 专门获取带有菜单选择的客户，避免返回无关数据
    Task<IEnumerable<Customer>> GetAllWithMenuSelectionsAsync(CancellationToken cancellationToken = default);
}

// 菜单选项仓储的特定接口，支持批量查询ID对应的菜单名称
public interface IMenuOptionRepository : IRepository<MenuOptions>
{
    Task<IDictionary<long, string>> GetMenuNamesByIdsAsync(IEnumerable<long> menuIds, CancellationToken cancellationToken = default);
}

2. 抽离可复用的菜单元数据服务 #

你提到这个映射逻辑会被RestaurantManagerService和SourcingService复用，那我们可以把菜单ID到名称的映射逻辑单独抽成一个独立服务，它只负责和菜单元数据打交道，完全和客户订单逻辑解耦：

using Microsoft.Extensions.Caching.Memory;

public class MenuMetadataService(IMenuOptionRepository menuRepo, IMemoryCache cache)
{
    // 缓存键和过期时间（菜单属于不常变更的静态数据，缓存1小时足够）
    private const string MenuIdNameCacheKey = "MenuIdToNameMap";
    private readonly TimeSpan _cacheExpiry = TimeSpan.FromHours(1);

    public async Task<IDictionary<long, string>> GetMenuNamesByIdsAsync(IEnumerable<long> menuIds, CancellationToken ct = default)
    {
        // 先从缓存获取全量菜单映射，避免每次查询都走数据库
        var fullMenuMap = await cache.GetOrCreateAsync(MenuIdNameCacheKey, async entry =>
        {
            entry.AbsoluteExpirationRelativeToNow = _cacheExpiry;
            var allMenus = await menuRepo.GetAllAsync(ct);
            return allMenus.ToDictionary(m => m.Id, m => m.MenuName);
        });

        // 只返回业务需要的ID对应的名称，避免返回多余数据
        return menuIds.Distinct()
            .ToDictionary(
                id => id,
                id => fullMenuMap.TryGetValue(id, out var name) ? name : "Unknown Menu"
            );
    }
}

这里用了内存缓存，完美解决你担心的“重复数据库调用”问题——如果多个服务调用这个方法，只要缓存没过期，就不会重复查库。如果菜单有更新，你可以在菜单的更新逻辑里主动清空缓存，保证数据一致性。

3. 重构MenuOrderService，专注于订单统计业务 #

现在MenuOrderService只需要专注于统计订单频次这一件事，菜单映射的逻辑完全交给上面的MenuMetadataService，彻底解耦Customer和MenuOptions：

public class MenuOrderService(ICustomerRepository customerRepo, MenuMetadataService menuMetaService)
{
    public async Task<Dictionary<string, int>> OrderMenusInKitchenAsync(CancellationToken ct = default)
    {
        // 1. 通过仓储获取客户数据（依赖接口，符合依赖倒置原则）
        var customers = await customerRepo.GetAllWithMenuSelectionsAsync(ct);

        // 2. 纯订单统计逻辑，完全不涉及菜单元数据
        var orderCountsById = customers
            .SelectMany(c => c.MenuSelection)
            .GroupBy(id => id)
            .ToDictionary(g => g.Key, g => g.Count());

        if (!orderCountsById.Any())
            return new Dictionary<string, int>();

        // 3. 复用MenuMetadataService获取菜单名称映射
        var menuNameMap = await menuMetaService.GetMenuNamesByIdsAsync(orderCountsById.Keys, ct);

        // 4. 转换为业务需要的结果
        return orderCountsById
            .ToDictionary(
                kvp => menuNameMap[kvp.Key],
                kvp => kvp.Value
            );
    }
}

解决你提到的几个关键疑问 #

1. 是否需要引入单独的服务处理两张表的数据？
   是的，就是上面的MenuMetadataService——它专门负责菜单元数据的访问和缓存，所有需要菜单ID到名称映射的服务（比如RestaurantManagerService）都可以直接注入这个服务，完全避免代码重复。

2. 是否要把菜单选项存为类变量？
   不推荐直接存在类变量里——因为类变量是服务生命周期内的静态数据，如果菜单更新了，只有重启服务才会更新。用内存缓存（或分布式缓存）更灵活，既可以设置过期时间，也可以主动触发缓存刷新，保证数据新鲜度。

3. 如何避免直接关联两张表？
   我们的方案完全做到了这一点：MenuOrderService只处理Customer的订单统计，MenuMetadataService只处理MenuOptions的元数据，两者通过“菜单ID”这个中立的标识交互，没有任何直接的实体关联或表关联逻辑。

额外的优化建议 #

• 单元测试更简单：因为所有服务都依赖抽象接口，你可以用Mock框架（比如Moq）模拟仓储和缓存，不用连接真实数据库就能测试业务逻辑。
• 扩展灵活性：如果以后要支持多餐厅的菜单，只需要给MenuMetadataService加个餐厅ID参数，或者扩展仓储接口，不用修改订单统计的逻辑。
• 异常处理：可以在仓储层或应用层加全局异常处理，比如处理数据库连接失败、缓存失效等情况，保证服务的健壮性。

内容来源于stack exchange