PDF/Office 文档生成在哪里适合 clean/onion 架构

Question

我需要将 docx/excel 报告添加到以下解决方案中

问题

我的文档生成适合在哪里？

解决方案说明

• 演示参考应用
• 应用参考域
• 基础设施未直接从上述项目引用
• 编号与依赖方向不匹配！例如。每个项目都引用了 Infrastructure.CrossCutting，但没有一个项目（DI 除外）引用了 DataAccess。

报告经常跨有界上下文查询数据，可能包括一些业务逻辑并具有框架依赖性（docx操作库），但另一方面查询必须进行性能优化（有时直接数据访问而不是使用存储库）

棘手的部分是在分离架构问题和维护成本之间找到适当的平衡，因为将报告分散在 4 层中也不是理想的选择。

Answer 1

生成报告（您案例中的实际文档）意味着您可以首先为此目的定义一个存储库对象：

// Domain
public interface IReportRepository
{
    string AddReport(IReportData data);
}

// Infrastructure
public class ReportRepository : IReportRepository
{
    public string AddReport(IReportData data)
    {
        // Use docx library (framework dependency) to generate report using 'data',
        // and return path to file.
    }
}

假设报告的数据是通过从不同的有界上下文中获取多个组件来聚合的，您可以坚持存储库模式并为不同的组件定义存储库对象：

// Domain
public interface IReportDataProvider
{
    object GetReportData();
}

// Infrastructure
public class ReportDataProvider1 : IReportDataProvider
{
    ...
}

// Infrastructure
public class ReportDataProvider2 : IReportDataProvider
{
    ...
}

用例实现：

{
    ...
    object data1 = this.provider1.GetReportData();
    object data2 = this.provider2.GetReportData();
    IReportData data = this.Process(data1, data2);
    string filePath = this.reportRepository.AddReport(data);
    ...
}

IReportDataProvider 可以实现为 API 调用，也可以实现为直接数据访问以获得更好的性能。这实际上取决于您如何看待此报告 API。

如果将 API 函数报告为协调器，则应设置提供程序来调用外部 API（在这种情况下，外部 API 执行自己的逻辑，而 Process 方法仅应用聚合逻辑）。

但是，如果这个 API 更像是一个完整的处理器，那么每个提供者都可以直接获取数据（在这种情况下，Process 方法应用完整的业务逻辑：data1 和 data2 的逻辑，加上聚合逻辑）。