如何在创建DTO时避免冗余业务逻辑(DB获取)

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

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

现在客户端请求以这种方式处理：

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

尽管Automapper减少了代码重复，但它的工作效果很好。实际问题是：

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

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