本文属于OData系列文章 Intro 前面写了很多有关OData使用的文章，很多读者会有疑问，直接将实体对象暴露给最终用户会不会有风险？$expand在默认配置的情况下，数据会不会有泄露风险？ 答案是肯定的，由于OData的特性，提供给我们便捷同时也会带来一些风险。很多地方推荐使用DTO模式来隔离
关于 Serializable的探讨 前提引入 是由于软件测试上有同学提到说,什么该字段在程序刚运行时,导致jvm激增,所以吸引了我的注意 回顾代码 MybatisPlus Generator自动生成的entity中就经常带有这个, 而且我在开发代码的时候VO,以及DTO常常是直接复制对应的enti
作者：宁海翔 1 前言 对象拷贝，是我们在开发过程中，绕不开的过程，既存在于Po、Dto、Do、Vo各个表现层数据的转换，也存在于系统交互如序列化、反序列化。 Java对象拷贝分为深拷贝和浅拷贝，目前常用的属性拷贝工具，包括Apache的BeanUtils、Spring的BeanUtils、Cgli
有时候，为了给前端页面输出内容，有时候我们需要准备和数据库不一样的实体信息，因为数据库可能记录的是一些引用的ID或者特殊字符，那么我们为了避免前端单独的进行转义处理，我们可以在后端进行统一的格式化后再行输出，后端处理可以采用不同的DTO尸体信息，后端对不同的实体进行映射处理即可，也可以采用同一个实体，在SqlSugar实体信息中忽略对应的字段写入实现，本篇随笔介绍后者的处理方式，实现在在工作流列表
该项目比较简单，只是单纯的把业务的dll模块和controller的dll做了一个动态的添加删除处理，目的就是插件开发。由于该项目过于简单，请勿吐槽。复杂的后续可以通过泛型的实体、dto等做业务和接口的动态区分。 项目结构如下： 上面的两个模块是独立通过dll加载道项目中的 repository动态
