Question

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

将整个Person对象发送给Accountant，或者创建一个新的PersonData对象只是为了保存数据并将其发送给Accountant obj会不会更好？

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

Answer 1

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

Answer 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
}

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

据我所知，C＃接口不能要求变量（如在大多数语言中），这会强制您创建访问器（除非有一些语言/ IDE功能来生成默认的普通访问器），如果还没有这样做的话...它比使用普通变量要花费更多的时间，并且需要比普通现场访问更多的性能，但OTOH，它也是我认为的良好实践，至少在事情没有获得性能时......我认为它比创建一个额外的DTO级并来回复制数据（或者至少在一个方向上）更优雅......

希望有帮助......;）

Answer 3

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

但是这样的OOP是非常理想化的，所以以另一种方式做它可能会更好......

Answer 4

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

Answer 5

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

OO / DTO架构问题

5 个答案: