在代码中重用数据契约作为对象模型的推荐模式是什么？答案

【问题标题】：What is the reccommended pattern for re-using a data contract as an object model in code?在代码中重用数据契约作为对象模型的推荐模式是什么？
【发布时间】：2019-03-18 19:45:24
【问题描述】：

假设我拥有一项服务并发布了类似的合同

public class MyObject
{
    public int Foo { get; }

    public string Bar { set; }
}

我认为在数据合同中存在“行为”是不合适的，例如

public class MyObject
{
    public int Foo { get; }

    public string Bar { set; }

    public void DoSomeAlgorithmWithMyProperties() { … }
}

换句话说，数据合约应该只是价值袋。

所以我的问题是如何在这样的对象上创建行为。我可以看到的一种方法是创建一个单独的镜像对象，例如

public class MyObjectInternal
{
    public int Foo { get; }

    public string Bar { set; }

    public class MyObjectInternal(int foo, string bar)
    {
        this.Foo = foo;
        this.Bar = bar;
    }

    public void DoSomeAlgorithmWithMyProperties() { … }
}

另一个是继承

public class MyObjectInternal : MyObject
{
    public class MyObjectInternal(int foo, string bar)
    {
        this.Foo = foo;
        this.Bar = bar;
    }

    public void DoSomeAlgorithmWithMyProperties() { … }
}

其他可能性可能是通过对值进行操作的单独类来完全分离行为和数据，例如

public static class MyObjectAlgorithmDoer
{
     public static void DoSomeAlgorithmWithMyProperties(MyObject myObject) { … }
}

【问题讨论】：

标签： c# .net oop design-patterns

【解决方案1】：

在您的情况下，使用继承不是正确的方法。我不明白为什么你认为继承可能对你有帮助？在您的情况下，使用继承是紧密耦合并且还会破坏封装（如果您有多个子类）对于抽象类也相同。我认为您可能需要Domain model pattern 并定义正确的值对象。我推荐你阅读patterns of enterprise application这本书，在这本书中介绍了不同的模式来创建你的领域模型。

【讨论】：

【解决方案2】：

我发现有两种方法可以将行为添加到 MyObject 合约中。一种方法是创建一个与MyObject 对话的服务，如下所示：

public class MyObjectService 
{
    public void DoOperation(MyObject myObject) 
    {
    }
}

MyObjectService 类然后可以被您的应用程序调用来执行操作。

在上述方法中，您拥有的是一个贫乏的域模型，您可以在其中将数据和对这些数据的操作彼此分开。这种方法的问题在于它可能导致代码重复，并且可能导致违反数据完整性。不过，如果您的应用程序很简单，这可能是一个不错的方法。

但是，如果您的系统复杂且不断发展，那么您可以关注Domain Driven Design。来自维基：

领域驱动设计的前提如下：

将项目的主要重点放在核心域和域逻辑上；

基于领域模型的复杂设计；

发起技术专家和领域专家之间的创造性合作，以迭代地改进概念模型，从而解决特定领域的问题。

DDD 一开始可能很难理解。我建议您在跳到解决方案之前完全理解这个概念。这里有一些很好的参考资料和教程来理解 DDD

【讨论】：