entity

由于微信支付费率是千分之六，在得知道建行龙支付可以做到千分之二，公司在成本这块就果断采取接建行，废话不说了直接贴代码 Service 层 相关的参数要求还得细对建行的文档 @Service public class CCBPayServiceImpl implements CCBPayApi { private static final Logger LOGGER = LoggerFactory.getLogger(CCBPayServiceImpl. class ); @Override public PayResult cCBPayment(PayRequestInfo payRequestInfo) throws BizException { BigDecimal orderPrice = TypeConversionUtil.getBigDecimal(payRequestInfo.getOrderPrice()); HashMap <String, String> map = new HashMap<String, String> (); map.put( "MERCHANTID" , CCBConstants.MERCHANTID); map.put( "POSID" , CCBConstants.POSID); map.put( "BRANCHID" ,

文章提纲 概述要点 理论基础 详细步骤 总结 概述要点 设计模式的产生，就是在对开发过程进行不断的抽象。 我们先看一下之前访问数据的典型过程。 在Controller中定义一个Context, 例如： private AccountContext db = new AccountContext(); 在Action中访问，例如获取用户列表： var users=db.SysUsers; 类似于这种，耦合性太高。业务逻辑直接访问数据存储层会导致一些问题，如 重复代码；不容易集中使用数据相关策略，例如缓存；后续维护，修改增加新功能不方便 等等。 我们使用repository来将业务层和数据实体层分开来，业务逻辑层应该对组成数据源层的数据类型不可知，比如数据源可能是数据库或者Web service 在数据源层和业务层之间增加一个repository层进行协调，有如下作用： 1.从数据源中查询数据 2.映射数据到业务实体 3.将业务实体数据的修改保存到数据源 （持久化数据） 这样repository就将业务逻辑和基础数据源的交互进行了分隔。 数据和业务层的分离有如下三个优点： 1.集中管理不同的底层数据源逻辑。 2.给单元测试提供分离点。 3.提供弹性架构，整体设计可以适应程序的不断进化。 我们将会对原有做法进行两轮抽象，实现我们想要的效果。 理论基础

由于微信支付费率是千分之六，在得知道建行龙支付可以做到千分之二，公司在成本这块就果断采取接建行，废话不说了直接贴代码 Service 层 相关的参数要求还得细对建行的文档 @Service public class CCBPayServiceImpl implements CCBPayApi { private static final Logger LOGGER = LoggerFactory.getLogger(CCBPayServiceImpl. class ); @Override public PayResult cCBPayment(PayRequestInfo payRequestInfo) throws BizException { BigDecimal orderPrice = TypeConversionUtil.getBigDecimal(payRequestInfo.getOrderPrice()); HashMap <String, String> map = new HashMap<String, String> (); map.put( "MERCHANTID" , CCBConstants.MERCHANTID); map.put( "POSID" , CCBConstants.POSID); map.put( "BRANCHID" ,

今天在用EF做插入操作的时候发现数据库中一个datetime类型的字段(CreateDate)的值居然全部为null。于是赶紧看表结构发现CreateDate字段居然是允许为空的。 虽然为空，但是设置了默认值getdate()，按说不应该为null的。于是开始测试。 字段允许Null值的情况 Users表结构如下： 假如一个字段有了默认值，并且又允许为Null，在做插入操作时会发生什么？ 如上图中的表结构，CreateDate是允许为null的，而又有默认值getdate()。这样在用传统SQL语句和EF做插入操作时分别会发生什么呢？ 先看传统SQL语句： insert into Users(Username,Password) values('test','123456') 插入结果： 使用SQL完全没有问题。 再看使用EF： Users user = new Users(); user.Username = "test2"; user.Password = "123456"; TestEntities entity = new TestEntities(); entity.Users.Add(user); int result = entity.SaveChanges(); 插入结果： 使用EF插入居然为NULL！！！于是立刻打开SQL Server

本文主要介绍了基于SpringMVC+mybatis对DDD思想的落地实现框架。本文为【DDD】系列文章中的其中一篇，其他内容可参考： 使用领域驱动设计思想实现业务系统 。 框架实现图 该框架实现基本和DDD的指导思想契合，主要分为四层，且将关注点放在了domain层。下面将逐层介绍各个组件的职责。 框架详述 User Interface层 门面层，对外以各种协议提供服务，该层需要明确定义支持的服务协议、契约等。包含： dto 包括request和response两部分，通过它定义入参和出参的契约，在dto层可以使用基础设施层的validation组件完成入参格式校验； controller 支持不同访问协议的控制器实现，比如：http/restful风格、tcp/二进制流协议、mq消息/json对象等等。 controller使用基础设施层公共组件完成许多通用的工作： 调用RequestMapping（SpringMVC公共组件）完成servlet路由； 调用checklogin完成登录态/权限校验； 调用logging组件完成日志记录； 调用message-resource组件完成错误信息转义，支持I18N； application层 service 应用服务层，组合domain层的领域对象和基础设施层的公共组件，根据业务需要包装出多变的服务，以适应多变的业务服务需求。

前言 cesium 官网的api文档介绍地址 cesium官网api ，里面详细的介绍 cesium 各个类的介绍，还有就是在线例子： cesium 官网在线例子 ，这个也是学习 cesium 的好素材。 之前有部分订阅者咨询我，cesium加载gltf模型点击弹窗以及模型列表点击定位弹窗那些交互是怎么实现的，虽说比较简单，但是总有新手是有这块需求的。所以，今天我抽空整理一下本篇素材，简单写一下。 实现效果图如下： 大概思路如下： gltf模型的模拟数据源配置，配置gltf模型路径以及气泡窗口显示内容json数据源 /* 三维模型gltf配置信息 */ MapConfig.mapPosition = Cesium.Cartesian3.fromDegrees(102.468086, 37.933179,3500 ); MapConfig.position = Cesium.Cartesian3.fromDegrees(102.468086, 37.933179 ); MapConfig.Obj3D = { position:MapConfig.mapPosition, models:[ { id: "1_db" , name : "测试3D模型1_db" , type: "gltf" , position : MapConfig.position, uri : "http:/

本文是本系列文章的第七篇，前6篇访问地址如下： 小书MybatisPlus第1篇-整合SpringBoot快速开始增删改查 小书MybatisPlus第2篇-条件构造器的应用及总结 小书MybatisPlus第3篇-自定义SQL 小书MybatisPlus第4篇-表格分页与下拉分页查询 小书MybatisPlus第5篇-Active Record模式精讲 小书MybatisPlus第6篇-主键生成策略精讲 一、代码生成器的基础实现原理 相信大部分的开发者都使用过或者听说过“模板引擎”，它可以帮我们实现视图与数据的分离，快速开发视图页面，并将模板整合结果用于在浏览器显示。其核心实现原理就是：HTML模板页面 + 页面数据 = 输出结果。页面视图输出的过程就是通过模板引擎实现的。 代码生成器的实现原理与模板引擎实现页面渲染的逻辑几乎是一致的，除了下面的几个区别： 所谓模板：就是某语言的代码 + 模板引擎语法的占位符，该占位符用来数据天换。所以代码生成器的模板文件不再专指HTML页面模板文件，可以是任何类型的代码文件。 模板引擎的输出结果在项目中是输出给浏览器进行页面渲染的，但是对于代码生成器而言，模板引擎的输出结果是保存到磁盘文件。 二、如何编写模板文件 要编写模板文件，首先我们要知道正常的代码待如何书写。比如下面的POJO代码： 上面的POJO代码写成Freemarker模板文件

问题： According to the HTTP/1.1 Spec: 根据HTTP / 1.1规范： The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line POST 方法用于请求源服务器接受请求中包含的实体作为 Request-Line Request-URI 标识的资源的新下属 In other words, POST is used to create . 换句话说， POST 用于 创建 。 The PUT method requests that the enclosed entity be stored under the supplied Request-URI . PUT 方法请求将封闭的实体存储在提供的 Request-URI 。 If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a

@[TOC] Zookeeper集群配置 Kafka重度依赖Zookeeper，所以必须选安装Zookeeper，下面是本机安装简单配置，因为只有一台机器，也没有使用虚拟机，所以使用了不同端口。 详细内容可以参考 Zookeeper集群安装 tickTime=2000 initLimit=10 syncLimit=5 dataDir=F:\zkkfk\data\zkdata\zk1 clientPort=2181 tickTime=2000 initLimit=10 syncLimit=5 dataDir=F:\zkkfk\data\zkdata\zk2 clientPort=2182 tickTime=2000 initLimit=10 syncLimit=5 dataDir=F:\zkkfk\data\zkdata\zk3 clientPort=2183 Kafka集群配置 下面是简单的Kafka的配置，集群中的broker.id一定要不同 broker.id=0 port=9092 log.dirs=F:\zkkfk\data\kfkdata\k1 zookeeper.connect=localhost:2181,localhost:2182,localhost:2183 zookeeper.connection.timeout.ms=6000 offsets.topic

起源 之前做的很多项目都使用solr/elasticsearch作为全文检索引擎，它们功能全面而强大，但是对于较小的项目而言，构建和维护成本显然过高，尤其是从关系数据库/文档数据库到全文检索引擎的数据同步工作非常繁琐，且容易出错。 记得很久以前就知道postgresql数据库内置全文检索，最近发现这个数据库越来越火，于是就又研究了一番，欣喜的发现居然支持ef core，于是对其进行了一些研究，并整理心得如下。 前提 本文假设读者熟悉entity framework core的基本概念和基本使用。 目的 建立dotnet core项目，使用postgres数据库和ef core，实现常见的全文检索功能，包括 建立索引字段 基本查询 查询结果排名 查询结果高亮显示 步骤1 - 新建项目并引入packages < Project Sdk ="Microsoft.NET.Sdk" > < PropertyGroup > < OutputType > Exe </ OutputType > < TargetFramework > netcoreapp3.1 </ TargetFramework > </ PropertyGroup > < ItemGroup > < PackageReference Include ="EFCore.NamingConventions" Version =