一种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 | 全部属性+父对象+子对象 |
博主简介:佘焕敏(shé),洋名 Billy Sir。
关注编程基础技术,并致力于研究软件的自动化生成。 对编程规范化、面向对象的极致使用也有着浓厚的兴趣。 同时非常希望能够写程序到65岁。
只有工匠精神,才能把常人觉得单调乏味的代码,当作作品雕刻成艺术品。
重点:这里几乎每一篇文章,都是我认真创作的,凝结了心血。写作从来都不是一件容易的事,对从小语文不好的我而言,是难上加难。而且,你发现没有,文中没有广告。这篇文章介绍了为什么要写这些文章。
![微信赞赏码](https://img2022.cnblogs.com/blog/33556/202211/33556-20221101085333455-1717538163.png)