DTO层的思考

注意,【】中是后来加的批注。因为随着对DDD的深入了解,对DTO的思考也有所改变。

分布式模式下,DTO层是一定需要的吗?

DTO层的作用是为了隔离Domain Model:让DoMain Model的改动不会直接影响到UI;保持Domain Model的安全,不暴露业务逻辑。

【最大多数情况看来,UI或者DO的改动,都不可避免地会影响对方,即使中间有DTO隔离,所以这一个理由是不成立的。
至于安全问题,如果不是开放性平台(业务接口的调用者不是安全的),那么也没必要担心业务逻辑会暴露;即使是开放性平台,我们也可以用AOP做权限检查,限制第三者的非法调用。所以安全问题的理由也不成立。】

有两个方案可以省略DTO层,又能起到DTO的作用:

l          继承:定义失血模型的Model,然后再做一个从Model继承的代理类 ,代理类里实现业务逻辑。贫血模型的Model单独为一个DLL,代理模型另起一个DLL。Client端只能引用贫血模型的DLL,这样就达到了隔离的目的,又省略了Contract层。

l          接口:为Domain Model做一个贫血模型的接口,接口单独为一个DLL,Client端只引用接口DLL。

这两种方案的核心思想都是让数据字段与业务方法分离,然后只对Client端公开数据部份。但这种思想会导致域模型趋向事务脚本模型,所以都不可取。

综上所述,在使用领域模型的情况下,如果没有DTO层,那么Model是一定会完整地暴露给Client端。

暴露Domain Model会带来什么问题?

首先是安全问题。

DoMain Model都带有业务方法,让Client端引用Domain Model就意味着Client端可以绕过Service层直接完成业务逻辑的调用。

【Client端直接调用Domian Model的方法,甚至直接调用Repository做持久化,在DDD的解决方案中是允许的。至于安全性问题已经在上面反驳过了。】

其次是效率问题。

Domain Model通常很“厚”(Model与Model嵌套得很深),在广域网上传输大对象会有严重的效率问题。

再有就是跨平台的问题。

Domain Model都是与特定的语言的数据类型有关,而这些数据类型是不能跨平台的,比如Java的类型就不能被C#使用。但在分布式模式下,Client端与Server端的平台不同是很正常的,如果Service直接返回Domain Model,Client端根本无法解析,这就要求Service返回的结果必须是标准的格式字节流。

让Domain Model只使用简单类型(字符和数值)?

让数据类型约束Domain Model显然不是一个好想法,所以DTO似乎是必不可少的了。

【是的,跨平台是DTO唯一存在的价值,JSON和XML大行其道并不是没有道理的】

如果我们一定要抛弃DTO层呢?

我们花这么大力气想省略DTO,就是因为这玩意太麻烦了,而且它的作用如此之小,代价却如此之大。

如果我们的系统只运行在局域网,网络都是光纤,我们有着强大的服务器,而且我们的开发人员严格地遵守Domain Model调用规则,只使用数据字段,不调用业务方法,并且我们的系统使用同一种语言开发,绝对不会跨平台……

我们把一切不利于暴露Domain Model的弱点都屏蔽之后,是不是意味着我们可以省略DTO层了?

嗯,看起来似乎是可以省略了。但前台开发人员真的能严格遵守调用规则吗?估计这时候,前台开发人员会进而质疑Service层的存在意义了……

【是的,在DDD中Client端是允许绕过Service,直接访问Domain Model的业务方法,以及Repository层,所以简单模块(只有crud,不用跨领域模块的功能)根本没有Service类。】

贫血模型 + 事务脚本模式

贫血模型和事务脚本模式都是与领域模型对立的,领域模型主张充血模型。

便贫血模型+事务脚本模式也有好处:

1.          开发简单。大多数的开发人员都有用过这种模式——以PetShop为代表的ADO.NET分层构架(MOD,DAL,BL)。

2.          可以安全地暴露业务模型,不用担心业务方法被非法调用。

时间: 2024-11-14 12:02:45

DTO层的思考的相关文章

Service层和DTO层的作用

Service层主要提供的几个作用:1.将业务逻辑层进行封装,对外提供业务服务调用.2.通过外观模式,屏蔽业务逻辑内部方法.3.降低业务逻辑层与UI层的依赖,业务逻辑接口或实现的变化不会影像UI层.4.降低UI层调用的请求次数及数据往返. DTO层主要提供的作用: 在上面的结构中,我们说了Service层的作用,目前还少加入了一层,DTO(数据传输对象层),该层负责屏蔽后端的实体层,将UI层需要的数据进行重新的定义和封装,在实际的业务场景下,后端实现或存储的数据远比用户需要的数据要庞大和复杂,所

[转]MVP模式开发

转自:http://www.jianshu.com/p/f7ff18ac1c31 基于面向协议MVP模式下的软件设计-(iOS篇) 字数9196 阅读505 评论3 喜欢11 基于面向协议MVP模式下的软件设计-(iOS篇) 传统模式下的开发 MVC MVVM 基于面向协议MVP的介绍 MVP实战开发 说在前面:相信就算你是个iOS新手也应该听说过MVC的,MVC是构建iOS App的标准模板.随着时间的推移,在iOS平台上MVC也逐渐开始面临着越来越多的问题,最近又开始流行MVVM,MVVM使

谈架构设计中DDD思想的运用

首先,描述一下我的业务场景及项目分层结构,非标准DDD(其实我不觉得有标准),只是思考的时候有带入DDD思想. 业务场景:这是一个ERP系统对中台提供的接口项目,仓储操作大多都是存储过程去完成的. 项目结构,如图: WebAPI层:这个不用多说了,入口. DTO层:增加数据传入传出对象,和领域model.实体model区分.(要不要围绕领域model或从现有系统中提取领域model看实际业务情况,拿我目前这个项目来说,得不偿失.) Services层:业务服务层(可以命名成BizServices

web项目的分层开发

没实习之前,一直在学校实验室做项目,项目比较简单,套个SSH或者SSM框架,就行了.项目大体分为了controller层.service层.dao层.domain层. controller层主要是与web页面相关的,比如页面中的一个"点赞"请求会根据配置文件或者注解映射到controller中对应的某个类(struts2)或者某个方法(springmvc). service层主要处理业务逻辑,比如"点赞"之后,系统有邮件通知你.为你加积分等这样的业务操作,都属于se

三层构架 和 MVC 是什么?

作者:肖继潮链接:https://www.zhihu.com/question/24291079/answer/27339010著作权归作者所有.商业转载请联系作者获得授权,非商业转载请注明出处. 企业应用开发时,经常采用三层架构分层:表示层.业务层.持久层. 表示层负责接收请求.转发请求.显示数据等: 业务层负责组织业务逻辑: 持久层负责持久化业务对象. 这三个分层,每一层都有不同的模式,就是架构模式.表示层最常用的架构模式就是MVC.因此,MVC是三层架构中表示层最常用的架构模式. 建议阅读

从接口、抽象类到工厂模式再到JVM来总结一些问题

俗话说,自己写的代码,6个月后也是别人的代码……复习!复习!复习! 涉及到的知识点总结如下: 为什么使用接口? 接口和抽象类的区别 简单工厂模式总结 Java中new和newInstance的区别 Java的Class.forName(xxx); Java里创建对象的几个方式总结 Java类加载机制总结 Java WEB的三层架构和MVC的关系 工厂方法模式总结 抽象工厂模式总结 一道面试题的分析 一个服务提供者框架的学习 接口的另一常用法:策略模式 参考资料 先看这样一个场景:某个果园里现在有

NET 分布式架构开发项目实战

.NET 分布式架构开发项目实战 从头到尾,一步一步讲述一个真实的项目实战,关注点主要是架构的思考和实现,以及如何解决平时项目遇到的一些问题. 同时也司公布源代码. 如何构建高性能,稳定SOA应用之-负载均衡-Decoupled Invocation 摘要: 当我们在为一个软件设计架构的时候,我们不仅仅要确保所做出来的架构要满足系统的业务需求,更加要确保做出来的架构要满足可维护性,安全,稳定性的非业务行的需求.另外一个非常重要的非功能性需求就是性能.性能涉及到很多方面的关注点,例如吞吐量,延迟等

踩过的坑 - 记录

1. 后台持久层Spring Jpa(即hibernate), 前台angularJS(angularJS只接受json串), 在后台使用DTO层对象代替domain(entity)与前台交互时, 传递的DTO对象中也包含对象,被包含对象也一定是对应domain的DTO, 因为只有DTO可以序列化和反序列化,用作于表现层的传递对象. 如下: public class VehicleAnnualAuditDTO { private Long id; private Boolean deleted;

WebService面试题

1. 四个概念      - soap :简单对象访问协议 http+xml     - Soa  :面向服务的架构,它是一种思想,IBM大力倡导           service 1   .service2  .Service3  , 服务都是面向web的 ,而且是即插即用的       IBM大力提倡,希望以组装电脑的方式来开发应用         组成:           1. 面向web的服务,面向web的组件  :WebService : 硬盘.cpu.内存条