一种DTO的规划方案

现在以网页发布的软件非常普遍，叫BS模式。前后端分离也是大趋势，或者说逐渐普及开来，深受前后端程序员的喜爱，我还是习惯以程序员来泛称所有软件制作者。后端需要把数据传送给前端，往往是通过DTO的序列化来实现的，而不是直接产生json或xml格式的数据。这里不说为什么要用DTO，只说探讨一个问题，不同的api接口（方法）返回不同格式的数据，这些DTO要如何设计。

特别说明，以下说到的DTO，是指DTO类，而不是DTO实例。虽然O应该是指实例，但这里继续用这个词，不阻碍意思的表述。

方案一，需要什么造什么。

这个方案简单，每个接口需要的数据结构不同就造不同的DTO，相同就复用。一般情况下能复用的不多，于是会出现大量的DTO，这些DTO的命名和管理成为难题。若规定一个接口独立使用一个DTO，则写这些DTO的工作量不小。还有一种粗糙的办法，假设有100个DTO，把它们按相近程度划分为少数若干类DTO，假设10类吧，然后同一类的DTO属性合并成一个DTO，这样确实能有效减少DTO的数量，但在具体的应用时，会多出来许多很是奇怪的属性。不可取。

方案二，照着对象造DTO

这里的对象可以简单理解为数据表，一个数据表对应一个DTO，但是多对多的关系表不对应DTO。造出来的DTO基本上与数据表的数量一样多（含统计功能的查询除外），有效的控制了DTO的数量，命名也方便。一个缺点是每个表的全部字段不管是否用到都在DTO中，有些字段只在少数情况下使用的，也得到处出现。另一个缺点是在DTO之间的关系上几乎总是造成循环引用。比如子对象往往要引用父对象，而父对象也有子对象的集合。不同接口往往只需要表现其中一个方向，但做出来的两个DTO类之间就必然有这种相互引用的关系，在自动生成api文档的时候，这种循环引用会是个问题，至今没有找到好的解决办法。

方案三，一个对象对应N个DTO

这N个DTO我作了规划：

类型	基类	范围
DTO1		只有ID和Name
DTO2	DTO1	只有常用的属性
DTO3	DTO2	有全部的属性，但不包含IsDeleted这类特殊的附加属性
DTO4	DTO3	包含了父对象
DTO5	DTO3	包含了子对象
DTO6	DTO4	包含了父对象和子对象

DTO4，DTO5，DTO6引用其它的DTO，作为泛型在具体使用的时候传入，并约束为对应的DTO1本身或子类。

这样，就可以以有限的数量的DTO，来组合表达足够灵活的结构，同时不会有输出太多多余的属性的情况。

也能解决DTO之间的循环引用问题，从而能使用swagger等生成api文档。

以学生和班级为例：

需要按条件查到若干个学生和每个学生对应的班级名称，则是结构是：

List<学生3<班级1>> 学生列表;

需要得到若干个班级，以及每个班级的部分符合指定条件的学生

List<班级5<学生2>>

需要得到指定老师所教的全部班级的学生，则是

老师5<班级5<学生2>>

缺点也是有的，DTO有6个，虽然有继承，不用重复写，但总比只有1个DTO要多写点代码。另外，这些DTO如何区分命名比较好，也是一个有待进一步完善的问题。如上表，是以数字123456区分的，应该有更好的命名方案。

2019-03 经过项目的实际使用, 调整为以下方案, 更适应实际的应用的需要。

类型	基类	范围
DTO1		ID和Name(Code)
DTO2	DTO1	只有常用的属性
DTO3	DTO2	全部属性（不包含IsDeleted这类特殊的附加属性，下同）
DTO4	DTO2	常用属性+父对象
DTO5	DTO2	常用属性+子对象
DTO6	DTO4	常用属性+父对象+子对象
DTO7	DTO3	全部属性+父对象
DTO8	DTO3	全部属性+子对象
DTO9	DTO7	全部属性+父对象+子对象