Question

我想知道在将DTO转换为域对象时，使用存储库是不是一个糟糕的设计。

我正在构建一个n层Web应用程序，它具有存储库层和服务层以及用于ORM的ef4。服务层公开域对象的DTO版本。当我从服务的消费者那里收到DTO时，该服务将使用AutoMapper将DTO转换为域对象。现在，域对象上的一些成员属性需要从数据库加载，例如我有下面的类 -

DTO版本：

public class LogonEventDto
{
    public DateTime Time
    {
        get;
        set;
    }

    public Guid UserId
    {
        get;
        set;
    }
}

域名版本：

public class LogonEvent
{
    public DateTime Time
    {
        get;
        set;
    }

    public User User
    {
        get;
        set;
    }
}

现在，在将DTO转换为DO版本时，我需要在UserRepository上调用GetById（）方法并使用结果设置LogonEvent.User属性。

只是为了通知您，我目前正在手动执行服务层中的所有转换逻辑。

正如我上面提到的，这是一个糟糕的设计决定，如果是这样，为什么？

Answer 1

我认为这样做是常识。您将内部状态表示（域模型）与服务合同（dto /数据合同）分离。这样您就不会暴露任何内部，并且您可以在不影响公共服务合同的情况下重构您的实现（假设仍然可以进行映射）。

我们在SOA（-isch）客户项目中始终使用此模式。我们甚至有一个工具来帮助您生成映射代码。

我不是AutoMapper的粉丝（尽管代码很酷），因为它要求你在运行时指定映射（你必须编写代码来构建映射def）。在我看来，映射定义是设计时的事情。这就是我们构建代码生成器工具的原因。

根据我的经验，我遇到了以下情况：

不要单独为每条记录获取数据（按Id）。而是在一次往返（数据库/数据源/其他Web服务）中组装要解决的ID列表，并让映射只是对检索到的批次执行查找。
由于源和目标之间存在大量对象和不同类层次结构的复杂映射，因此很难概述已映射的内容，位置和方式。目前还没有真正的解决方案 - 除了构建一个可以帮助你的工具。

希望它有所帮助。 Grtx，Marc

使用存储库的Object Mapper

1 个答案: