c# - 创建DTO时如何避免冗余业务逻辑(DB fetching)？

Question

我正在使用 C# 开发 N 层应用程序。服务器端由以下层组成:

• 数据访问层(EF 代码优先实体和 DbContext)
• 业务层(包含所有业务逻辑和对象)
• WCF 服务层(从业务层公开一些操作的每次调用实例化服务)

现在客户端请求是这样处理的:

1. Client创建Request DTO并发送给Service层
2. 服务层将此DTO映射到业务对象并调用BL方法
3. 业务层做一些有用的事情，向 DAL 发出请求，然后返回一些业务对象给服务
4. 服务层将业务对象映射到DTO响应并返回给客户端

尽管 Automapper 减轻了代码重复，但它工作得很好。实际问题是这样的:

客户端在不同的 View 中显示相同的对象:网格、表单等。例如，网格(列表) View 只需要来自用户对象的 Id 和名称，而表单(详细信息) View 需要每个用户的属性。但是业务层对 View 一无所知。它只能向服务调用提供完整的 UserBL 对象，然后由服务负责将此 UserBL 映射到 UserListDto 或 UserDetailsDto。对于一些重对象，从数据库中获取额外的字段会成为性能问题。

那么，业务层是否应该为不同的客户端操作提供不同的方法呢？我不喜欢这个解决方案，因为它看起来像域逻辑污染，但我不知道还能做什么。

Answer 1

Client shows same objects in different views: grid, form, etc. For example, grid(list) view requires only Id and Name from User object, while Form(details) view needs every User's property. But Business layer knows nothing about views. It can only provide full UserBL object to Service calls and then it's the Service responsibility to map this UserBL to UserListDto or UserDetailsDto. And for some heavy objects, fetching extra fields from DB become a performance issue.

我通常根据 BL 中执行的操作类型返回业务实体的不同表示。例如，当搜索返回用户的搜索表示时，它只包含身份用户所需的最少属性集。当获取特定用户时，我返回一个完整的业务对象。

关于您的代码重复问题。这不是重复。用户的这些不同表示具有不同的职责。

• DTO:负责传输用户并在业务层和消费者之间建立松耦合
• BO:负责封装和执行业务操作
• DB实体:负责使BO对象持久化无知

因此，如果您只使用一种用户表示形式，您将合并所有这些职责，因此必须牺牲良好的设计才能让每个人都能使用它。唯一真正的好处是你必须少写几行代码。当您开始维护已发布的应用程序时，请记住这一点。您节省了几行代码，但维护起来却困难得多。