OO / DTO 架构问题答案

【问题标题】：OO / DTO Architecture questionOO / DTO 架构问题
【发布时间】：2009-12-22 19:46:50
【问题描述】：

我们有一个包含数据和方法的实体（类）（我们称之为 Person）。还有其他类需要使用此对象中的数据（我们称其中之一为 Accountant），但不需要使用其方法中的功能。

最好将整个 Person 对象发送给 Accountant，还是创建一个新的 PersonData 对象来保存数据并将其发送给 Accountant obj？

我们确实有一个案例需要解决这个问题，但我想知道最好的通用答案，以便我们在整个过程中使用它。

【问题讨论】：

标签： design-patterns oop dto

【解决方案1】：

通常，您会在需要以某种序列化形式使用数据的地方移交 DTO - 例如通过 Web 服务或智能客户端。如果您只是在域中使用 Person 对象，并且已经正确封装，为什么还要努力创建 DTO？

【讨论】：

【解决方案2】：

正如其他人所说，使用 DTO 没有任何意义，除非不涉及传输...... :)

我建议的解决方案是将传递给Accountant 的对象抽象为接口IAccountee 并让Person 实现它......我不熟悉C#（从你的个人资料来看，我推断这是您选择的语言:) )，但这可能会为您指明正确的方向：

class Accountant {
    //....
    public void performAction(IAccountee target) 
    {

    }
}
interface IAccountee
{
    string Name
    {
        get;
    }
    int Salary
    {
        get;
        set;
    }
}

class Person : IAccountee
{
    //implementation here, as well as some stuff specific to Person
}

基本上，这就是SOLID 中的D :) ...它既灵活又干净，也避免了与Accountant 共享来自Person 的不必要信息...

据我了解，C# 接口不能需要变量（就像在大多数语言中一样），这会迫使您创建访问器（除非有一些语言/IDE 功能可以生成默认的普通访问器），如果您还没有这样做的话...它比使用普通变量更耗时，并且需要比普通字段访问更多的性能，但是 OTOH，这也是我认为好的做法，至少当事情没有得到性能时......我认为这绝对比创建一个额外的 DTO 类和来回复制数据（或至少在一个方向）更优雅......

希望对您有所帮助... ;)

【讨论】：

你为什么要使用 IAccountee：它只是为了方便地传递变量还是我缺少什么？
它将 Accountant 与 Person 解耦，并将所有对 Accountant 不必要的东西隐藏在 Accountant 本身...

【解决方案3】：

我会说 OOP 会让您使用在 person 类中定义的“get”方法。我不会发送整个对象，因为会计不需要整个对象，只需要选择性数据。我不会说后者，因为您正在创建不必要的大量冗余。

但是像这样的 OOP 是高度理想化的，所以换一种方式可能会更好......

【讨论】：

【解决方案4】：

我通常保留使用 DTO 进行跨层数据传输。如果不是这种情况，我不确定创建一个令人信服的理由。

【讨论】：

【解决方案5】：

我认为这是一个信任边界问题。在业务应用程序中，信任边界通常决定了您的层架构。如果您的“会计师”在 Person 的信任边界之外，那么应该进行某种模型转换。架构和需求应该决定什么样的转换。

【讨论】：