Jvm 对象何时符合DTO的条件？

DTO（数据传输对象）是用于在应用程序的多个子系统之间传输信息的对象，通常由网络或进程边界隔开。这是我的理解

然而，从Java的角度来看，子系统/模块是否必须位于不同的JVM实例上，才能将它们之间使用的对象定义为DTO？（我认为，就子系统之间的模块性和功能性而言，架构上的重大划分就足够了。）你怎么说

此外，考虑到架构的同一层/层中的多个模块交换的对象，这些对象不符合DTO的条件吗？是否强制实行分层

提前谢谢

问候,

---

Nagendra U M

因为在层之间传输对象需要某种序列化，所以它被视为DTO。在层之间传输对象通常是通过使用域实体来完成的，因此不需要序列化

因此，DTO通常不具有仅用于保存数据的行为属性

需要注意的是：当实体没有行为，只有数据时，DTO常常被误认为是贫血对象。或者，当对象仅用于在方法或类中传输数据，然后消失时，就使用恶作剧对象

例如，有时数据持久性机制要求您实现或继承不希望耦合到域层的接口或类，因此您可以创建继承或实现接口/类的对象，并将数据传输到这些类以实现持久性

class Person{
public string Name {get;set;}
public int Age {get;set;}

public void Validate(){}
public void DoSomething(){}
}



public class PersonDTO : TableServiceContext
{
public const string ContactTableName = "PersonTable"

public string Name {get;set;}
public int Age {get;set;}

}

---

您通常会有一个类来组装和分解这些对象。

谢谢您的回答。好的我同意DTO主要只有数据，很少或根本没有行为。但是，要将DTO称为DTO，序列化是必需的吗？只要我们能够区分子系统之间的界限，并通过不可序列化的对象（假设子系统共享同一个JVM）在子系统之间建立一个交换数据的契约，我们还不能将这些对象称为DTO吗？（至少在原则上）？？关于在体系结构层之间和内部移动的对象的第二个问题仍然没有答案。在这方面，Nagendra U MFowler指出DTO用于减少远程调用并同时序列化所有数据。尽管今天我认为我们使用它的目的不止于此，例如我的示例，它的主要重点不是减少昂贵的调用，而是不将我的域模型与数据持久性机制耦合以进行远程传输。至于架构问题，我不认为它们是DTO，因为这些对象不受远程传输的约束，而远程传输正是DTO的目的。