dto

曾经有个项目，遇到一个情况就是DTO需要“频繁”的转成JsonObject进行传递（因为用的框架是 Vert.x,用EventBus通信）存在明显的性能消耗。或者使用框架带的DTO自定义，但是一看就没麻烦就没有操作。 需要频繁的操作如下: JSONObject jo= (JSONObject) JSONObject.toJSON(fooBean); FooBean fooBean= (FooBean)JSONObject.toBean(jo, FooBean.class); 为了提高性能，做的就是改造DTO，思路如下： 本来DTO的属性是本来是以全局变量存在各自的类中，现在把这类全部去掉，改成维护在JsonObject 中。因为操作相同，把所有的DTO都改成继承同一个基础的DTO ，在基础的DTO中统一维护。 1.为了适配其他框架的实例化，还是要保留相应的get/set，但是get/set操作的其实是JsonObject 2.为了非String类型的数据，做相关方法的改写。 //-----------BaseJsonDTO .java----- public class BaseJsonDTO { private static Logger logger = LoggerFactory.getLogger(RespGenerator.class); private static

一、前言 测试妹子反馈了一个bug，说后台报了个服务器异常——保存一个数量比较大的值时，比如 9999，一直在转圈圈，直到最后报了一个服务器异常。我接过了这个bug，经过仔细查看代码后发现，代码卡在了一个批量插入的SQL语句上，就是比如前端保存 9999 的时候，后端的业务逻辑要进行 9999 次的批量插入。 二、方案一 最开始的SQL语句是这样的，传入一个List，由MyBatis 处理这个 List 拼接成一个SQL语句并执行，看着也没有什么大问题呀！ INSERT INTO yy_marketing_coupon ( uuid, no, name, type, money, status, instruction, astrict, total_number, remain_number, send_mode, get_mode, use_mode, user_rank_lower, send_start_time, send_end_time, use_start_time, use_end_time, use_expire_time, discount, user_mobiles, create_time, creater, update_time, updater, appid, use_car_type, highest_money, term_type,

返回总目录 本篇目录 验证介绍 使用数据注解 自定义验证 标准化 验证介绍### 首先应该验证应用的输入。用户或者其它应用都可以向该应用发送输入。在一个web应用中，验证通常要实现两次：在客户端和服务器端。客户端的验证大多数情况下是为用户体验而实现的。在客户端最好先检查一下表单，并向用户展示不合法的字段。但是服务端的验证更关键且不可避免。 服务端的验证通常实现在应用服务层。应用服务方法应首先检查（验证）输入然后再使用它。ABP提供了一个很好的基础设施来验证应用服务方法的输入。 应用服务方法接收一个DTO（数据传输对象）作为输入。ABP有一个 IValidate 接口，凡是实现了该接口的DTO都可以自动地进行验证。因为 IInputDto 继承了IValidate，因此只要为输入DTOs实现IInputDto就可以确保验证了。 使用数据注解### ABP支持数据注解特性。假设我们要开发一个任务（Task）应用服务，该服务用于创建一个任务，它的输入参数类型如下所示： public class CreateTaskInput : IInputDto { public int? AssignedPersonId { get; set; } [Required] public string Description { get; set; } } 这里， Description 属性标记为

如果你对项目管理、系统架构有兴趣，请加微信订阅号“softjg”，加入这个PM、架构师的大家庭 在ddd设计中我们经常会提到服务层，服务层是什么？职责是什么？有什么好处？。 先看简单的层次图（注：这里并没有考虑其他多余的领域逻辑数据层存储，或者UOW这些细节） 我的理解是服务层是处于我的应用程序业务层和表现层之间的应用程序边界,边界可能是很薄的一层类设计或者是分布式服务网络跃点。它是一个与技术无关的名词。由表现层直接调用，契约，执行命令（修改状态（CUD））或者是查询返回dto（数据迁移对象）（cms，命令-查询分离）。他对业务逻辑层接口很清楚，组织业务逻辑 微服务形成宏服务，适配表现层。 这里谈到宏服务和微服务，宏服务有一些列粗粒度的服务组成。用户的一次操作usecase，比如电子商务下单，CreateOrder就是一个宏服务，而不是下单中的细粒度的商品库存检查，订单合法性等。而与之对应的微服务（有时也叫应用程序服务），则表现为问题领域逻辑细节，就如上面的库存检查和合法性检查这些细粒度的服务。宏服务是由一个或者多个微服务组成，有时我们的usecase逻辑很简单服务层仅由单一微服务组成，变现为很简单的几句微服务调用。 服务层的职责： 1：在面软件开发不管是结构化编程（sp）还是面向对象编程（oop）我们一直都强调高内聚低耦合，分离关注点（soc）。服务层处于应用程序和业务层之间

1、POJO、VO、BO、DTO、PO 关系？ VO、BO、DTO、PO 都是 POJO 的一种类别，是 POJO 在不同使用场景下的不同叫法。 2、POJO、VO、BO、DTO、PO 是什么？ POJO POJO的概念连接 VO VO (View Object,表现层对象), 封装整个界面展示所需要的对象数据。 BO BO (Business Object, 业务对象), 封装业务逻辑的java对象，通过调用DAO方法，结合PO,VO进行业务操作。 DTO DTO (Data Transfer Object, 数据传输对象)。PO在传输前的再封装对象。 简单来说，当我们需要一个对象10个字段的内容，但这个对象对应的PO总共有20个字段，我们不需要把整个PO对象全部字段传输到客户端，而是可以用DTO重新封装，传递到客户端。 PO PO (Persistent Object,持久对象) ,每个属性基本上都对应数据库表里面的某个字段。 参考文献 https://www.cnblogs.com/lyjin/p/6389349.html Java各种对象（PO,BO,VO,DTO,POJO,DAO,Entity,JavaBean,JavaBeans）的区分 来源： CSDN 作者： doforfuturedx 链接： https://blog.csdn.net/u013617791

注意，【】中是后来加的批注。因为随着对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 端公开数据部份