这是正确使用 DTO 吗？

Question

我正在编写一个控制台应用程序，它可以从存储过程记录集中进行大量数据检索。对于我正在使用的每种记录集类型，我都有一个使用 EF 和自定义复杂类型来检索数据的存储库：

public interface IBalanceSheetRepository
{
    IEnumerable<BalanceSheetRecordDTO> GetBalanceSheetRecords();
}

public class BalanceSheetRepository : IBalanceSheetRepository
{
    DBContext _context;

    ...

    public IEnumerable<BalanceSheetRecordDTO> GetBalanceSheetRecords()
    {
        ObjectResult<BalanceSheetRecord> results = _context.GetBalanceSheet();
        return results.Select(CreateBalanceSheetDTOFromDAO);
    }

    private static BalanceSheetRecordDTO CreateBalanceSheetDTOFromDAO(BalanceSheetRecord dao)
    {
        return new BalanceSheetRecordDTO { ... };
    }
}

这里，BalanceSheetRecord 是我在设计器中创建的复杂数据类型。我创建了一个 DTO 以避免耦合，因为 BLL 不应该知道 BalanceSheetRecord 类型。

这是我的问题：由于 DTO 类型用于存储库接口的方法签名中，并且由于我的 BLL 最终将使用存储库并返回 DTO 的集合，因此这似乎是一个横切关注点。因此，我将 DTO 与 repo 接口一起生活在一个单独的“基础设施”程序集中。这是我想要实现的目标的好做法，还是我在某个地方走错了路？

另外：在我的存储库中更新数据上下文是不好的做法吗？当两个组件都属于 DAL 时，一定数量的耦合是否可以？我想使用 DI，但它似乎更有用，例如将 repo 的 DBContext 实现换成TestBalanceSheetRepository。

Answer 1

我更喜欢从我的存储库中返回实际实体。这样，当您需要在服务层中协调不同实体之间的复杂交互时，就无需来回转换为 DTO。然后，服务层在向应用层返回数据时将实体投影到 DTO 中。

我知道有些纯粹主义者说层之间的所有交互都应该使用 DTO 完成，但我认为这不切实际。无论如何，服务层最终都会与实体耦合，所以这不像您要添加耦合。

它还限制了 DTO 到服务层的实体的投影/展平。这对我来说是一个加分项，因为这些活动增加了复杂性并降低了性能。

您的数据上下文是您的工作单元。 “每个存储库一个工作单元”的想法是一种反模式。工作单元应由服务层限定范围，它可能涉及来自 1-many 存储库的 1-many 实体。如果每个存储库都有不同的工作单元，您将无法让服务层调用轻松维护一致的事务。