建议将数据协定重用为代码中的对象模型的模式是什么?

Question

假设我拥有一个服务并发布了一个合约，例如

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) { … }
}

Answer 1

我看到有两种方法可以在MyObject合同中添加行为。一种方法是创建一个与MyObject通信的服务，如下所示：

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

然后，应用程序可以调用MyObjectService类来执行该操作。

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

但是，如果您的系统复杂且不断发展，那么您可以遵循领域驱动设计。来自维基：

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

• 将项目的主要重点放在核心领域和领域逻辑上;
• 基于域模型的复杂设计;
• 在技术和领域专家之间发起创造性协作，以迭代方式完善概念模型，以解决 特定域问题。

DDD 最初可能很难遵循。我建议您在跳到解决方案之前完全理解该概念。这里有一些很好的参考和教程来理解DDD

• https://airbrake.io/blog/software-design/domain-driven-design
• 复数课程：https://www.pluralsight.com/courses/refactoring-anemic-domain-model

Answer 2

在您的情况下，使用继承不是一种正确的方法。我不明白你为什么认为继承会对你有帮助？在您的情况下，使用继承是紧密耦合的，并且封装中的中断(如果您有多个子类(对于抽象类也是如此。我认为您可能需要域模型模式并定义适当的值对象。我建议您阅读企业应用模式一书，在本书中介绍不同的模式来创建您的领域模型。