c# - 关于何时需要特定 DTO 类的另一个讨论

Question

我正在从事一个大型项目，该项目部分是要替换现有的服务器堆栈。对于一个非常规范化的大型数据库，很明显我们需要构建许多复合对象。我的一个查询的一个例子是这样的:我的复合对象定义:

[DataContract]
public class CompositeEvent
{
    Guid eventIdentity;
    string accountIdentity;
    string eventMessage;
    DateTime eventLoggedOn;
    string methodName;
    string programName;
    string userIdentity;
    List<CompositeException> exceptions = new List<CompositeException>( );
    List<CompositeParameter> methodParameters = new List<CompositeParameter>( );
    List<CompositeParameter> databaseParameters = new List<CompositeParameter>( );

    [DataMember]
    public Guid EventIdentity
    {
        get { return eventIdentity; }
        set { eventIdentity = value; }
    }
    [DataMember]
    public string AccountIdentity
    {
        get { return accountIdentity; }
        set { accountIdentity = value; }
    }
    [DataMember]
    public string EventMessage
    {
        get { return eventMessage; }
        set { eventMessage = value; }
    }

    [DataMember]
    public DateTime EventLoggedOn
    {
        get { return eventLoggedOn; }
        set { eventLoggedOn = value; }
    }

    [DataMember]
    public string MethodName
    {
        get { return methodName; }
        set { methodName = value; }
    }

    [DataMember]
    public string ProgramName
    {
        get { return programName; }
        set { programName = value; }
    }

    [DataMember]
    public string UserIdentity
    {
        get { return userIdentity; }
        set { userIdentity = value; }
    }

    public string QualifiedCreator
    {
        get 
        {
            if ( String.IsNullOrEmpty( programName ) && String.IsNullOrEmpty( methodName ) )
                return string.Empty;
            return string.Format( "{0}:{1}", String.IsNullOrEmpty( ProgramName ) ? "{undefined}" : ProgramName, String.IsNullOrEmpty( MethodName ) ? "{undefined}" : MethodName );
        }
    }
    [DataMember]
    public int EventTypeIdentity { get; set; }

    [DataMember]
    public string EventTypeName { get; set; }

    [DataMember]
    public List<CompositeException> Exceptions
    {
        get { return exceptions; }
        set { exceptions = value; }
    }

    [DataMember]
    public List<CompositeParameter> MethodParameters
    {
        get { return methodParameters; }
        set { methodParameters = value; }
    }

    [DataMember]
    public List<CompositeParameter> DatabaseParameters
    {
        get { return databaseParameters; }
        set { databaseParameters = value; }
    }
}

我的服务中的数据库查询:

            using ( Framework.Data.FrameworkDataEntities context = new Data.FrameworkDataEntities( ) )
        {
            var list = from item in context.EventLogs
                       join typeName in context.EventLogTypes on item.EventTypeId equals typeName.Id
                       orderby item.EventLoggedOn, item.EventLogType
                       select new CompositeEvent
                       {
                           AccountIdentity = item.AccountIdentity,
                           EventIdentity = item.Id,
                           EventLoggedOn = item.EventLoggedOn,
                           EventMessage = item.EventMessage,
                           EventTypeIdentity = item.EventTypeId,
                           EventTypeName = typeName.EventTypeName,
                           MethodName = item.MethodName,
                           ProgramName = item.ProgramName,
                           UserIdentity = item.UserIdentity
                       };
            return new List<CompositeEvent>( list );
        }

现在从我的复合对象的定义中可以清楚地看出它只包含数据，没有业务规则，也没有业务结构、数据结构或任何其他内容的其他持久化或暴露。

然而我的队友说这只能存在于域模型中，我必须花时间将我的数据从这个定义明确的对象移动到 DTO。不仅如此，而且 a) 所有 DTO 的名称中都必须包含 DTO，并且 b) 它们的存在必须只是为了在网络中移动。因此，当我们开发客户端代码时，它必须 a) 创建每个对象属性的属性，以及 b) 从 DTO 移动到 View 模型属性。

我感觉这是把DTO发挥到了极致。基于复合对象的定义，这些是数据传输对象。此外，我认为将此对象存储在客户端中并直接绑定(bind)到客户端中的此对象绝对没有问题。由于我所做的只是获取复合对象中定义的每个属性并将它们复制到 DTO 中，创建一个对象只是为了将其复制到另一个对象然后再次将其复制到内部似乎是对时间和周期的巨大浪费客户端的属性。

我对关于此的其他意见很感兴趣。我觉得我没有违反任何 OOP 规则，例如关注点分离或单一职责原则……至少只要您不对这些规则变得非常厌恶。意见????

Answer 1

好吧，您同事强调的所有必须让他看起来有点强制症。但这没关系，因为他确实有道理。

DTO，尤其是 MVC 中的 DTO，应该以这样一种方式进行设计，使它们抽象出底层数据模型，以便它们成为 View 的实际模型。让它们靠近您的对象只会导致您修改两组对象，而实际上可能只有其中一个需要更改。

在 SoA 或 N 层架构中设计 DTO 时要考虑的另一件事是，它们不应在您的 View 层与底层服务和模型之间创建契约。因此，如果数据库中发生某些变化(字段、表、 View 等)，您应该能够从服务层开始调整所有内容，并以不影响 DTO 的方式进行调整。

View 模型应该保持不变，至少只要您不在其中添加或删除功能。任何潜在的变化都应该适应 DTO(不是绕过的方式 - 但这并不总是可能的)。

现在我应该提一下，我现在正在将一个项目从 SoA 和 DTO 切换到普通的 2 层架构(这是因为性能问题，而不是 DTO:))。我有一个包含简单对象和复杂对象的横切域层，旨在仅供内部使用。任何通过 Web 服务公开的 API 都将使用 DTO，因为我不想杀死 WS 消费者。也许会伤害他们一点 :)。

但是您应该按照我上面提到的方式使用 DTO。它将对您的情况有所帮助(使用 MVC)。为了更容易映射到 DTO，反之亦然，我建议 AutoMapper .会让你的生活更轻松(让你的同事开心)。