.NET EF - 如何使用干净架构方法避免不同数据库上下文中相同模型的代码重复

Question

我正在为基于 .NET 6 的多租户应用程序构建一个 Web API 后端，并且我遇到了一个架构问题，自过去几周以来，这个问题让我发疯，所以我非常感谢任何提示和建议。

整个解决方案是建立在经典的清洁架构（层：API、域、应用程序、基础设施、共享）中，这不是我认为最好的想法，但恐怕现在是不可逆转的。无论如何，我想努力拯救我迄今为止所创造的一切。

在应用程序中，我有 2 个数据库（后面的代码中包含实体框架）：

• 数据库 A：租户用户范围 - 每个表中都有 TenantId 列，用于在 SQL 级别实现的 RLS 机制，以防止租户间的交互数据泄漏
• 数据库 B：内部用户范围 - 无 RLS 机制

问题在于两个数据库共享大量共同的结构和逻辑。

当前模型（数据库和域）的简化示例：

数据库 A：

public class TenantEmployee 
{
    public Guid Id { get; protected set; }
    public string Name { get; protected set; }
    public string DepartmentId { get; protected set; }

    public void SetName(string name) { ... }
    public void SetDepartment(string id) { ... }
    public int GetWorkingHours() { ... }
}

数据库 B：

public class InternalEmployee 
{
    public Guid Id { get; protected set; }
    public string Name { get; protected set; }
    public string DepartmentId { get; protected set; }

    public void SetName(string name) { ... }
    public void SetDepartment(string id) { ... }
    public int GetWorkingHours() { ... }
}

目前，使用 CQRS （MediatR）我必须实现如下逻辑：

• “CreateTenantEmployeeCommand”
• “CreateInternalEmployeeCommand”
• “GetTenantEmployeeDataQuery”
• “GetInternalEmployeeDataQuery”

等。

这样我正在创建大量重复代码。

我不想为这些类创建通用接口，因为我认为这可能会在未来的某个时候终止应用程序的开发（模型可能随时变得有点不同）。

有一个想法是在基础设施层中创建贫乏的数据库模型，如下所示

internal class TenantEmployee 
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public string DepartmentId { get; set; }
}

internal class InternalEmployee 
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public string DepartmentId { get; set; }
}

然后创建公共域模型（在域层中），如下所示：

public class Employee 
{
    public Guid Id { get; protected set; }
    public string Name { get; protected set; }
    public string DepartmentId { get; protected set; }
 
    public void SetName(string name) { ... }
    public void SetDepartment(string id) { ... }
    public int GetWorkingHours() { ... }
}

在这种方法中，我可以将域逻辑保留在一个位置并使用接受域模型的通用存储库模式用于输入和输出以及将域模型映射到数据库模型并返回的内部存储库逻辑。这种解决方案仍然在某些区域给我留下了重复的代码，但我想它可以让我在应用程序和域层中阻止它。

尽管如此，我还是想确保我没有错过任何更好的解决方案。

Answer 1

这样我就创建了大量的代码重复。我不想为这些类创建通用接口，因为我认为这可能会在未来的某个时候终止应用程序的开发（模型可能随时变得有点不同）。

如果您有太多重复，那么您认为应该合并代码是正确的。如果两个模型都应该能够具有通用代码，和特定代码，那么解决您的问题的方法可能是多态性。

我建议有两个新类 Domain.TenantEmployee 和 Domain.InternalEmployee 都继承自抽象 Domain.Employee。您可以将常见行为放在父类中，将特定行为放在子类中。

然后，您的基础设施层可以将 Domain.TenantEmployee 与 DatabaseA.TenantEmployee 相互转换，将 Domain.InternalEmployee 从/到 DatabaseB.InternalEmployee< 相互转换/代码>。