我考虑使用DTO代替传递我的领域对象。我已经在这里和其他地方读了几篇文章，我知道有几种方法可以完成这个过程。
如果我总共只有大约10个领域类，并且考虑到我想在我的视图（WPF前端）中使用DTO而不是领域对象，那么推荐的方法是什么。 我认为在我的情况下使用像automapper之类的工具可能会过度kill，因此我想编写自己的mapper类，该类将具有用于将领域类型转换为DTO类型的方法。
如何做到这一点最好的方式是什么，是否有任何样例可以让我开始做这个？
第二个问题：在编写创建DTO的方法时，如何处理设置所有数据，特别是当领域类型引用其他领域对象时？为映射到领域类中的那些引用类型编写DTO中的等效属性吗？ 如果我没有正确表达我的第二个问题，请问。但我认为你明白我试图询问什么。
第三个问题：在编写DTO时，我应该编写多个DTO，每个DTO都包含给定模型的部分数据，以便可以用来满足特定视图的要求，还是DTO应该具有对应的模型类中所有数据。
我在这里阅读了一些有关DTO的帖子，似乎很多人认为它们等同于我所认为的ViewModel。 DTO就是数据传输对象 - 它是通过网络传输的内容。因此，我有一个网站和服务，只有服务才能访问实际的领域/实体对象，并返回DTO。这些可能是1:1映射的，但请考虑DTO可能是从另一个服务调用、数据库查询、读取配置文件等填充的。
之后，网站可以接收这些DTO并将其添加到ViewModel中，或者转换成ViewModel。该ViewModel可能包含许多不同类型的DTO。一个简单的例子是任务管理器 - ViewModel包含正在编辑的任务对象以及一组可以分配任务的Dto.User对象。
请记住，返回DTO的服务可能被网站、平板电脑或手机应用程序使用。这些应用程序将具有不同的视图以利用其显示效果，因此ViewModel将不同，但DTO将保持不变。
无论如何，我喜欢这些类型的讨论，所以请让我知道您的想法。
Matt
我在一个项目中正在使用DTOs。我倾向于只创建展示特定视图所需数据的DTOs。我在我的数据访问类中获取所有在视图中显示的数据。例如，我可能会有一个Order对象，它引用了一个Client对象：
public class Client{
public int Id{get;set;}
public string Name{get;set;}
}
public class Order{
public int OrderID{get;set;}
public Client client{get;set;}
public double Total{get;set;}
public IEnumerable<OrderLine> lines {get;set;}
}
那么在我的 OrderListDTO 中，我可能会有这样的内容：
public class OrderListDTO{
public int OrderId{get;set;}
public string ClientName{get;set;}
...
}
我想在视图中显示哪些字段。我在数据库访问代码中获取了所有这些字段，因此不需要在视图或控制器代码中处理实体关联。
最佳开发DTO的方式
开始开发DTO的方法是要理解它们的唯一目的是将业务实体的子集数据传输给不同的客户端（可以是UI或外部服务）。在这种理解下，您可以为每个客户端创建单独的包...并编写DTO类。对于映射，您可以编写自己的映射器，定义要传递给工厂的接口，根据这些接口创建DTO对象，该对象基于正在创建DTO的实体中提取数据。您还可以定义要放置在实体字段上的注释，但就我个人而言，我更喜欢使用接口方式，因为使用的注释数量太多。关于DTO的主要注意事项是它们也是类，DTO之间的数据应该被重用，换句话说，虽然为每个用例创建DTO可能很诱人，但要尽量重用现有的DTO来最小化其数量。
入门指南
关于入门，如上所述，DTO的唯一目的是为客户端提供所需的数据，因此您可以考虑只使用setter将数据设置到DTO中...或者定义一个从接口到实体的工厂，根据接口从实体创建DTO......
关于您的第三个问题，请根据客户端的要求执行 :)
我参与了一个使用 spring-jdbc 的项目，其中使用了 DAO 层。有时现有的实体并不能涵盖数据库中所有可能的数据。因此，我开始使用 DTO。
通过应用“70结构编程规则”，我将所有DTO放入单独的包中：
package com.evil.dao; // DAO interfaces for IOC.
package com.evil.dao.impl; // DAO implementation classes.
package com.evil.dao.dto; // DTOs
现在我重新思考并决定将所有没有重用的结果集DTO作为DAO接口上的内部类。所以DAO接口看起来像这样：
interface StatisticDao {
class StatisticDto {
int count;
double amount;
String type;
public static void extract(ResultSet rs, StatisticDto dto) { ... }
}
List<StatisticDto> getStatistic(Criteria criteria);
}
class StatisticDaoImpl implements StatisticDao {
List<StatisticDto> getStatistic(Criteria criteria) {
...
RowCallbackHandler callback = new RowCallbackHandler() {
@Override
public void processRow(ResultSet rs) throws SQLException {
StatisticDao.StatisticDto.extract(rs, dto);
// make action on dto
}
}
namedTemplate.query(query, queryParams, callback);
}
}
我认为将相关数据放在一起（使用自定义DTO和DAO接口）可以使代码更适合PageUp/PageDown。
如果您需要澄清，请询问。
我假设你的领域模型对象有一个主键ID，它可能对应于它们来自的数据库或存储中的ID。
如果以上内容属实，则你的DTO将克服类型引用其他DTO的问题，就像你的领域对象一样，以外键ID的形式存在。因此，领域对象上的OrderLine.OrderHeader关系将在DTO中表示为OrderLine.OrderHeaderId。
希望这可以帮到你。
我可以问一下，为什么你选择在视图中使用DTO而不是你丰富的领域对象吗？
Dtos（可能）。但重要的是是否过度使用DTO。Dtos传输数据是一种好的实践，但会给开发团队带来巨大的负担。Daos）交互。因此，您始终需要使用DTO将数据传输到/从远程（进程外）。
2.使用Dtos在服务之间传递数据是可选的。如果您不打算将项目分解为微服务，则没有必要这样做。这只会增加负担。