这是DTO的正确用法吗？我正在编写一个控制台应用程序，它从存储过程记录集中进行批量数据检索。对于我使用的每种记录集类型，我都有一个使用EF的存储库和一个自定义复杂类型来检索数据：}公共类BalanceSheetRepository:IBalanceSheetRepository{DBContext_context;...publicIEnumerableGetBalanceSheetRecords(){ObjectResult结果=_context.GetBalanceSheet();返回结果。选择（CreateBalanceSheetDTOFromDAO）；}privatestaticBalanceSheetRecordDTOCreateBalanceSheetDTOFromDAO(BalanceSheetRecorddao){returnnewBalanceSheetRecordDTO{...};在这里，BalanceSheetRecord是我设计的在.我创建了一个DTO以避免耦合，因为BLL不应该知道BalanceSheetRecord类型。这是我的问题：由于DTO类型用于存储库接口的方法签名，并且由于我的BLL最终将使用存储库并返回DTO集合，这似乎是一个交叉问题。因此，我让DTO与repo接口一起存在于一个单独的“基础设施”组件中。这是我想要实现的良好做法，还是我在某个地方走错了路？另外：在我的存储库中创建新的数据上下文是不好的做法吗？当两个组件都属于DAL时是否存在一定程度的耦合？我想使用DI，但替换TestBalanceSheetRepository的repo的DBContext实现似乎更有用。我更喜欢从我的存储库中返回实际实体。这样，当您需要协调服务层中不同实体之间的复杂交互时，无需来回转换为DTO。然后，当向应用层返回数据时，服务层将实体投影到DTO中。我知道一些纯粹主义者说层之间的所有交互都应该使用DTO来完成，但我发现那是不切实际的。无论如何，服务层最终都会耦合到实体，所以这不像是在添加耦合。它还将DTO的投影/扁平化限制为实体到服务层。对我来说，这是一个优势，因为这些活动增加了复杂性并降低了性能。您的数据上下文是您的工作单元。“每个存储库一个工作单元”的想法是一种反模式。工作单元应由服务层确定范围，服务层可能涉及来自1-many存储库的1-many实体。如果每个存储库都有不同的工作单元，您将失去使服务层调用轻松维护一致事务的能力。以上是C#学习教程：这是DTO的正确使用方法吗？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
