Question

我们正在开始一个新的多层架构。过去，我使用AutoMapper将数据传输对象映射到业务对象，反之亦然。一位同事建议我们应该将业务对象中的dto包装起来，而不是映射。可能是通过在业务对象的构造函数中注入dto。然后我们可以在不进行映射的情况下即时访问dto的属性值。

问题：

推荐这种方法吗？

我知道如果业务对象知道你引入了紧耦合。此外，通过在业务对象和dto之间创建1：1关系，您可以放松一些灵活性，通常 - 灵活映射 - 将是n：m关系。

（见：Best Practices For Mapping DTO to Domain Object?）

这个缺点是没有人似乎使用包装方法或者我错过了吗？

这是一个快速演示我的意思＆＃34;包装＆＃34;：

＆＃13;

public class BusinessObject
{
    private Dto dto;

    public BusinessObject()
    {
        this.dto = new Dto();
    }

    public BusinessObject(Dto dto)
    {
        this.dto = dto;
    }


    public int Id
    {
        get { return dto.Id; }
        set { dto.Id = value; }
    }
}

public class Dto
{
    public int Id { get; set; }
}

＆＃13;

向你寻求帮助！

的Torsten

Answer 1

这是一个有争议的问题。我首先在blog post中看到了这种方法。

好处很明显。它确实简化并简化了代码。现在，您的业务对象（POCO）不必重新创建DTO已涵盖的一组访问器和更改器，而只需引用DTO的属性。创建业务对象也更容易，因为您只需将DTO传递给业务对象构造函数，并且现在更容易持久化业务对象，因为您只需要抓取对象的DTO部分。

这种方法有一些缺点。正如您所指出的，您现在或多或少地被固定为1-1映射。另一个缺点是，您正在失去任何validation or business logic您的业务对象可能对您的对象的某些属性强制执行（因为DTO现在拥有它们）。

将DTO填充到业务对象（POCO）中的一个相当大的缺点是它可能在代码中留下的行为，其中对象往往不再管理自己的状态。作为expressed here，这可以使得定位负责特定功能的代码变得更加困难。当对象的外部状态设置时，它也会使类的使用更加危险。

将dto包装在业务对象中 - 一个好主意？

1 个答案: