在非分布式项目中使用DTO

之前公司的项目b/s，非分布式，小项目，使用了DTO，感觉特别的麻烦。依我个人理解，1、使用DTO是为了将底层的持久对象一些数据隐藏起来，但是在非分布式项目中，这样做似乎多余了；2、组合数据减少调用逻辑方法的次数。
百度查过资料，看到有一个人说使用DTO的好处是，方便后期维护，假如持久对象发生改变了，可以不需要更改表现层，只需更改DTO转换就可以，我觉得这样做反而没有不使用DTO来的更方便。
在我看来，在非分布式项目中不适合使用DTO。是这样的？

5 个解决方案

#1

你确实是在做 .net 产品？

传递 Model，用直接的序列化方式即可，在任何使用数据实体的地方直接使用 Model 而不需要过度包装。

java 中有大堆垃圾概念，它们把相同的东西加入少量接口，然后“深度继承”，说成是各种概念。这其实是“竖井化思维”的体现。

Model 对象既可以用于数据持久化，也可以用于层间传递数据。比如说数据持久化就是类似

var db = new MyDbContext();

db.Save(myobj);

这样的 ORM 代码就能保存数据。而那些很扯的分层代码却非要写

var DbObj = new DbObj();

DbObj.CopyFrom(myobj);

DbObj.Save();

这就是过度封装，它们认为每一个 Model 都要另外封装为一个用来具有数据库 Save、Delete 操作的 DAL 类型，它们也认为每一个 Model 都要另外封装为一个用来序列化或者层间传递的新的类型。

你说的1.和2，可能有些人觉得比较“顺理成章”，然后在我们的角度则一眼就能看出其问题来，原因就在规划软件的角度根本不同。你的那种观点，是“自底向上”来拼凑的思路，满脑子都是数据库增删改查，所以你认为 Model 只能是你的数据库表中僵化对应的那些东西，这在 .net 中就叫做 DB First 的思考方式。

而我们实际上把 Model 看作是层间通讯（声明参数）的根据，而关系数据库表中只有一小部分数据表是跟 Model 直接对应的，数据库层代码是事先开发完成、然后自动适配各种实体对象的 Save、Delete等操作（而不需要在修改了数据库定义之后去重新修改 DAL 代码），这在 .net 中就是 Code First 的思考方式。我们把 EF、ORM，甚至 ADO.NET 丢叫做 DAL层（顶多就是编写100多行的提高效率的 SqlHelper 代码），根本用不着像“xxxx生成器”那样去再去产生什么DAL层代码。

你可以看到，由于先入为主地把 Model 看的很低级地仅跟关系数据库表僵化对应，于是就诡异地封装出许多很多“浅浅的层”的概念。

#2

大多数 java 开发者喜欢 java 社区中胡乱封装概念，缺乏删除冗余层的勇气。

#3

引用楼主 gp55_ 的回复:

我觉得这样做反而没有不使用DTO来的更方便。
在我看来，在非分布式项目中不适合使用DTO。是这样的？

这其实就是“和稀泥”。你既不能理解那种“自底向上拼凑”的人的思路，又不能理解那些“精简到恰好适当”的人思路。表面上看，你找出了一个理由，其实是把问题复杂化了。因为这个理由太浅，太没有定性。

#4

dto是为了将数据持久化部分与实际的业务模型解耦……
即理论上只要业务模型不发生变化，那数据模型可以随便变，只要两者的互转不存在任何问题

#5

DTO是领域驱动模型的一个概念，建模用的。不存在非分布式项目，我觉得不能用DTO这么一说~

#1

var db = new MyDbContext();

db.Save(myobj);