dto

MapStruct用途 在我们项目中，我们经常要处理将DTO转换成VO,DTO转成Entity等各类对象相互转换，如果我们采用BeanUtils工具类的copyProperty进行转换，很容易出现转换性能低，类型转换错误等问题。 与其他转换工具相对，MapStruct具有以下优点： 通过使用普通方法调用而不是反射来快速执行 编译时类型安全性：只能映射相互映射的对象和属性，不能将订单实体意外映射到客户DTO等。 Maven配置 . . . < properties > < org . mapstruct . version > 1.3 .1 . Final < / org . mapstruct . version > < / properties > . . . < dependencies > < dependency > < groupId > org . mapstruct < / groupId > < artifactId > mapstruct - jdk8 < / artifactId > < version > $ { org . mapstruct . version } < / version > < / dependency > < dependency > < groupId > org . mapstruct < / groupId > <

原文：http://www.tracefact.net/Software-design/Model-View-Presenter-Pattern.aspx 出处： http://msdn.microsoft.com/en-us/magazine/cc188690.aspx 引言 随着像Asp.Net和Windows窗体这样的用户界面创建技术越来越强大，让用户界面层做多于它本应做的事是很常见的。没有一个清晰的职责划分，UI层经常沦为一个包含实际上应属于程序其他层的逻辑的容器。有一个称为 模型(Model)-视图(View)-提供器(Presenter)(MVP)的设计模式，特别适合解决这个问题。为了表明我的观点，我将为Northwind数据库中的客户建一个遵循MVP模式的显示屏幕(display screen)。 为什么在UI层包含太多的逻辑是很糟糕的？在既不手动运行应用程序，也不维护丑陋的自动执行UI组件的UI运行者脚本(runner script)的情况下，位于应用程序UI层中的代码是非常难于调试的。虽然这本身就是一个很大的问题，一个更大的问题是在应用程序的公共视图之间会有大量的重复代码。当执行某一特定业务的功能在UI层的不同部分之间拷贝，通常很难找到好的可选重构方法。MVP设计模式使得将UI层中的逻辑和代码 重构为 更加易于测试的新型的、可重用的代码 更加容易。 图1

今天接到一个需求，是将公司的一些统计数据文件内容解析出来后，通过mq发给用户运营平台，给公司的大佬看，这个还是很简单，半个小时就码完了，但自测完后突然发现怎么建了这么多DTO（data transform object）！因为统计文件有很多不同类型，我针对每个类型都建了相应的DTO，因为这个DTO在其他业务也用不上，而且以后文件类型还有增加的话，那DTO也会增加，仅仅因为这单个小功能产生这么多利用率不高的DTO着实不太好（论项目是如何变臃肿的），所以我想到了一个办法，建一个外部类，然后将这些文件对应的DTO作为内部类放在里面。但是内部类是用普通类还是静态类呢？其实我也不知道，所以我好好研究了一番他们的区别。 我先贴下网上找到的关于普通内部类和静态内部类的区别： 普通内部类持有对外部类的引用，静态内部类没有持有外部类的引用。 普通内部类能够访问外部类的静态和非静态成员，静态内部类不能访问外部类的非静态成员，他只能访问外部类的静态成员。 一个普通内部类不能脱离外部类实体被创建，且可以访问外部类的数据和方法，因为他就在外部类里面。 是不是一脸懵逼，哪里引用了外部类？我怎么没看见？其实我看完后也是一脸懵逼，后来我猜想，这些是不是jvm将java文件编译成class文件的过程中帮我们做了点手脚？为了验证猜想，于是乎做了下面实验。 我先写了一个很简单的普通内部类和静态内部类的代码：

前言：在DDD系列文章里面，我们在后台仓储里面封装了传递Lamada表达式的通用方法，类似这样： 　　　　　public virtual IQueryable<TEntity> Find(Expression<Func<TEntity, bool>> express) { Func<TEntity, bool> lamada = express.Compile(); return UnitOfWork.context.Set<TEntity>().Where(lamada).AsQueryable<TEntity>(); } 通过前端传过来的Lamada表达式，直接放到Where条件里面查询。那么问题来了，我们前端如何传入Lamada呢？当然，有人说了，这个不用传啊，前端直接.Find(x=>x.Name=="abc")这样写就好了啊。确实，如果前端条件只有一个条件，你确实可以这样简单处理，但是实际开发的过程中，我们很多时候是需要传递多个参数，并且.Find(x=>x.Name=="abc")这种写法也不利于方法的封装。于是，我们神奇的动态Lamada诞生了。 一、再谈Lamada表达式 1、匿名委托 之前在介绍委托的时候我们介绍过一种特殊的匿名委托，它型如： class Program { private delegate void SayHello(string name);

今天在Review一个老项目的时候，看到一段奇怪的代码。 if (dto.Payment == null) continue; var entity = entries.FirstOrDefault(e => e.LedgerEntryID == dto.LedgerEntryID); dto.Payment = entity?.Payment; 　 其中dto.Payment是一个 PaymentDTO 类的实例，entity?.Payment是一个 Payment 类的实例， PaymentDTO 类和 Payment 类没有子父关系，所以不存在子类和父类之间的隐式转换。 奇怪的是Visual Studio的编译器没有提示任何编译错误。 打开PaymentDTO类的定义之后，发现了以下方法签名。 public static implicit operator PaymentDTO(Payment payment) 从方法签名上看，这就是重写PaymentDTO类型的操作符，但并不是我以前常用的+,-,*,/, ==等。 查询MSDN之后，才了解到implicit和explicit是一对转换操作符。 Implicit和Explicit Implicit Implicit关键字用于声明隐式的用户定义类型转换运算符。它可以实现2个不同类的隐式转换 ，提高代码的可读性

报错日志 今天在因项目需求，在DTO实体类中加了个字段就炸了bug错误 java.io.InvalidClassException: com.lenovo.quotation.dto.QuoteSettingDTO; local class incompatible: stream classdesc serialVersionUID = -1296272934669966307, local class serialVersionUID = 1020939123400497762 解决 问题原因：因为写实体类时 implements Serializable ，但没有写 private static final long serialVersionUID 。导致本地缓存的实体类DTO与改后的DTO的随机生成的serialVersionUID不一样 两种方法解决： 1，清空项目的缓存。重新加载新的数据 2，在实体类上加上 serialVersionUID 。 来源： CSDN 作者： baiofchao 链接： https://blog.csdn.net/baiofchao/article/details/104274621

应用服务和领域模型的边界在哪里？ 处理边界往往是一个比较棘手的问题。就像处理三八线一样，有的时候你会感觉对方的地盘属于你的，对方又感觉你的地盘属于他，然后要求重新重新划分。边界往往就是这样，经常出现冲突。 应用服务和领域模型的边界就没有像两个思想作怪那么复杂，因为他们具有规则和逻辑。所以只要弄懂什么是服务，什么是领域模型就可以解决这看似混乱的边界。 应用服务与领域模型的产生 应用服务和领域模型的出现是软件开发历史进程中的产物。在最开始的领域逻辑是混沌的，并没有领域模型，只是简单的事务脚本。在这个时期，一个脚本就对应一个业务用例。对于简单的业务来说这没什么问题，而且还很方便。但是当事务脚本中操作的模型对象超过两个以上，这时事务脚本就变得复杂起来，他完成了这些模型对象所有的业务逻辑。在这个时期事务脚本担任着全部的业务逻辑。随着业务复杂性的增加，人们解决问题域的抽象也变得更加接近现实。此时非过程化的面向对象编程也逐渐流行起来，所以也是时候将事务脚本的业务逻辑交给领域模型来解决了。从此事务脚本被一分为二，领域模型反应了细粒度业务逻辑，但是细粒度的领域模型在使用的过程又比较麻烦且繁琐，我们的业务流程常以粗粒度的用例模型来表达，所以我们需要一组类将细粒度的领域模型封装成粗粒度的用例模型供客户调用，这组封装的用例模型类叫做应用服务类。 应用服务包含什么内容？ 上面是从业务的角度分析应用服务的产生

我们在做着表面上看似是对于各种不同应用的开发，其实背后所对应的架构设计都是相对稳定的。在一个好的架构下编程，不仅对于开发人员是一件赏心悦目的事情，更重要的是软件能够表现出一个健康的姿态；而架构设计的不合理，不仅让开发人员受苦受难，软件本身的生命周期更是受到严重威胁。这里我将针对在微软dotNet平台上做应用开发系统的一般架构流程设计做一个粗浅的讨论。 总体设计图 表示层 表示层由UI（User Interface）和UI控制逻辑组成。 l UI（User Interface） UI是客户端的用户界面，负责从用户方接收命令，请求，数据，传递给业务层处理，然后将结果呈现出来。根据客户端的不同我们大体将应用程序分为BS（Browser-Server） 浏览器结构，CS（Client-Server）桌面客户端结构。 BS的优点是无需操心客户端，只需要部署维护好服务器即可。CS的优点在于强大的界面交互表达能力。RIA（Rich Internet Application）是为了融合这两种结构优点的一种技术，它依赖在客户端一次性安装一个通用解释器之后即获得强大的界面交互表达能力和无需部署具体客户端的方便性。具体的实现技术很多，例如微软的SmartClient， Avalon； Macromedia的Flex；以JS为基础的Bindows；Ajax等等很多。 UI控制逻辑