使用DTO和POCO对象时,处理导航属性的最佳做法是什么？

Question

我正试图围绕领域驱动开发.我想确保我有一个良好的基础和理解它,所以如果在这里避免使用AutoMapper或类似的建议会很好.我的架构目前涉及以下内容:

• WCF服务负责持久性(使用实体框架)和服务器端验证.它将POCO转换为DTO,并将DTO转移到客户端.

• 客户接收DTO并将其转换为POCO.转换POCO和DTO的类在服务和客户端之间共享.

• POCO的实现IValidatableObject和INotifyPropertyChanged服务器和客户端都使用它们,但它们不用于数据传输.DTO是,只是不包含任何行为的财产袋.

(1)问题#1.此架构是否适用于域驱动设计.
(2)问题#2.POCO是否适合包含导航属性？对于POCO来说,在DDD架构中包含导航属性对我来说真的是错误的,因为对我来说,拥有可能序列化或不序列化的导航属性是没有意义的.拥有专门的DTO对我来说更有意义.

例如,这是POCO/DTO在我的架构中的样子.

// Enforces consistency between a POCO and DTO
public interface IExample
{
    Int32 Id { get; set; }
    String Name { get; set; }
}

// POCO
public class Example : IExample, INotifyPropertyChanged, IValidatableObject
{
    private int id;
    private string name;

    public Int32 Id {
        get { return this.id; }
        set {
            this.id = value;
            OnPropertyChanged("Id");
        }
    }

    public String Name {
        get { return this.name; }
        set {
            this.name = value;
            OnPropertyChanged("Name ");
        }
    }

    public ICollection<Example2> ChildExamples {
        get { ... }
        set { ... }
    }

    // INotifyPropertyChanged Members
    // IValidatableObject Members
}

// DTO
public class ExampleInfo : IExample
{
    public Int32 Id { get; set; }
    public String Name { get; set; }
    public ICollection<Example2Info> ChildExamples { get; set; }
}

但它似乎并不正确,因为您可能并不总是需要导航属性,并且在面向对象的体系结构中使用空(null)对象(或集合)似乎非常错误.您还必须有时处理序列化和转换深层对象层次结构,这并非易事.对于专门的DTO来说更有意义,因此对于可能需要或可能不需要序列化或填充的空导航属性的持续可能性没有问题.

public class ComplexInfo
{
    public Example ExampleInfo { get; set; }
    public ICollection<Example2Info> ChildExamples { get; set; }
}

如何在现实企业DDD样式架构中处理这些情况,以及可以在此处提供哪些其他建议？

Answer 1

我同意Jehof关于将DTO发送给您的客户并在您的WCF下保持域模型在服务器端的清洁.

关于导航属性,Eric Evans在Domain Driven Design中强调的一点是尊重不变量.那么,在上面的例子中,问问自己Id和Name是否真的会在对象的生命周期中发生变化,或者它们是不变量？很多DDD风格的开发人员甚至都不会在这些属性上放置一个setter.而是通过构造函数构建对象的不变状态.如果Name可以更改,您可能需要一个名为Rename(string newName)的方法,因为您可能希望在那里放置某种业务规则.

上面图层中的红色标记是您在DAL中拥有整个对象模型.你所说的程序集真的不是什么大问题,但我认为这表明你倾向于从数据的角度思考应用程序.DDD的要点是根据逻辑和行为来考虑您的对象模型,而不是数据和结构.我(以及大多数其他DDD开发人员,我认为)将数据访问层视为返回Aggregate Roots的Repository类.存储库负责将您的水合poco /实体对象从DAL(存储库)返回到业务层(以及上面的应用程序/服务层类或上例中的WCF).在使用EF的情况下,您将拥有存储库包装DataContext调用并返回实体对象.

我可以继续下去,因为你的问题实际上是针对DDD的基本原理,其中有几个.我建议1)阅读Eric Evans的书"Domain Driven Design".2)请记住,DDD针对的是复杂的商业软件.如果你试图将它应用到一个简单的CRUD应用程序,它实际上只是UI表单和数据绑定到数据库表,很难看到DDD方法的形成,因为它解决的问题不存在.所以请保持透视.

Answer 2

领域驱动设计与 POCO 或 DTO 无关。它涉及实体、聚合根、值对象。关于除了数据之外还可以封装行为的丰富域对象。

POCO 包含导航属性是否合适？

我不清楚 POCO 在您的场景中有何用途，但如果它们是您的域实体，那么它们可以而且应该包含导航属性。实际上，使用聚合根（一种特殊类型的域实体）的导航属性通常是外部对象访问该聚合中包含的实体的唯一方法。通过关联属性进行导航是 DDD 中的一个关键概念。

此外，DDD 中推荐的架构看起来或多或少类似于：

• 表示层（UI）
• 应用层
• 领域层
• 基础设施层（包括持久性/DAL）

这里的关键是单一职责原则。您不希望服务同时执行持久性、服务器端验证和 DTO 映射。你需要解耦。您需要在各层之间明确分配职责，以便它们更易于维护、扩展和移植。