dapper

1. 为什么会有/怎么解决: async/await的无限嵌套 public async Task<int> myFuncAsync1() { //some code 　　int num = await getNumberFromDatabaseAsync(); //如果没有await那么async修饰的函数仍然是同步执行，失去意义 　　return num; } public async Task<string> myFuncAsync2() {　 　　//some code 　　int num = await myFuncAsync1(); //因为用await等待async函数，所以此函数也要标记为async 　　string s = ""+ num.toString(); 　　return s; } public async Task<int> myFuncAsync3() { ... } ... 第一次遇到async/await是在做一个智能家居的网络控制程序上，为了不阻塞UI，老同事说把其中有的方法改成了async，让后端修改数据库的逻辑异步执行，返回操作结果之后再刷新UI，可是发现把一个函数标记成async之后，你就必须在这个函数里头有await的对象（通常也是一个异步函数）才能让async真的异步，否则即使标记async函数仍然会同步执行

我们一直在追求架构的艺术！！ 问题分析 经过几分钟的排查，数据库情况如下： 数据库采用Sqlserver 2008 R2，单表数据量21亿。 无水平或者垂直切分，但是采用了分区表。分区表策略是按时间降序分的区，将近30个分区。正因为分区表的原因，系统才保证了在性能不是太差的情况下坚持至今。 此表除聚集索引之外，无其他索引，无主键（主键其实是利用索引来快速查重的）。所以在频繁插入新数据的情况下，索引调整所耗费的性能比较低。 至于聚集索引和非聚集索引等知识，请各位移步google或者百度。 至于业务，不是太复杂。经过相关人员咨询，大约40%的请求为单条Insert，大约60%的请求为按class_id 和in_time（倒序）分页获取数据。Select请求全部命中聚集索引，所以性能非常高。这也是聚集索引之所以这样设计的目的。 解决问题 由于单表数据量已经超过21亿，并且2017年以前的数据几乎不影响业务，所以决定把2017年以前（不包括2017年）的数据迁移到新表，仅供以后特殊业务查询使用。经过查询大约有9亿数据量。 数据迁移工作包括三个个步骤： 从源数据表查询出要迁移的数据 把数据插入新表 把旧表的数据删除 传统做法 这里申明一点，就算是传统的做法也需要分页获取源数据，因为你的内存一次性装载不下9亿条数据。 从源数据表分页获取数据，具体分页条数，太少则查询原表太频繁，太多则查询太慢。

本文将介绍微服务架构和相关的组件，介绍他们是什么以及为什么要使用微服务架构和这些组件。本文侧重于简明地表达微服务架构的全局图景，因此不会涉及具体如何使用组件等细节。 为了防止不提供原网址的转载，特在这里加上原文链接： https://www.cnblogs.com/skabyy/p/11396571.html 要理解微服务，首先要先理解不是微服务的那些。通常跟微服务相对的是单体应用，即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的，这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程。 最初的需求 几年前，小明和小皮一起创业做网上超市。小明负责程序开发，小皮负责其他事宜。当时互联网还不发达，网上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单，只需要一个网站挂在公网，用户能够在这个网站上浏览商品、购买商品；另外还需一个管理后台，可以管理商品、用户、以及订单数据。 我们整理一下功能清单： 网站 用户注册、登录功能 商品展示 下单 管理后台 用户管理 商品管理 订单管理 由于需求简单，小明左手右手一个慢动作，网站就做好了。管理后台出于安全考虑，不和网站做在一起，小明右手左手慢动作重播，管理网站也做好了。总体架构图如下： 小明挥一挥手，找了家云服务部署上去，网站就上线了。上线后好评如潮，深受各类肥宅喜爱

文章开头先给大家出一道面试题： 在设计某小型项目的数据库（假设用的是 MySQL）时，如果给用户表（User）添加一个字段（Roles）用来存储用户的角色，你会给这个字段设置什么类型？提示：要考虑到角色在后端开发时需要用枚举表示，且一个用户可能会拥有多个角色。 映入你脑海的第一个答案可能是：varchar 类型，用分隔符的方式来存储多个角色，比如用 1|2|3 或 1,2,3 来表示用户拥有多个角色。当然如果角色数量可能超过个位数，考虑到数据库的查询方便（比如用 INSTR 或 POSITION 来判断用户是否包含某个角色），角色的值至少要从数字 10 开始。方案是可行的，可是不是太简单了，有没有更好的方案？更好的回答应是整型（int、bigint 等），优点是写 SQL 查询条件更方便，性能、空间上都优于 varchar。但整型毕竟只是一个数字，怎么表示多个角色呢？此时想到了二进制位操作的你，心中应该早有了答案。且保留你心中的答案，接着看完本文，或许你会有意外的收获，因为实际应用中可能还会遇到一连串的问题。为了更好的说明后面的问题，我们先来回顾一下枚举的基础知识。 枚举基础 枚举类型的作用是限制其变量只能从有限的选项中取值，这些选项（枚举类型的成员）各自对应于一个数字，数字默认从 0 开始，并以此递增。例如： public enum Days { Sunday, Monday,

【.NET Core项目实战-统一认证平台】开篇及目录索引 上篇文章介绍了 IdentityServer4 的源码分析的内容，让我们知道了 IdentityServer4 的一些运行原理，这篇将介绍如何使用dapper来持久化 Identityserver4 ，让我们对 IdentityServer4 理解更透彻，并优化下数据请求，减少不必要的开销。 .netcore项目实战交流群（637326624），有兴趣的朋友可以在群里交流讨论。 一、数据如何实现持久化 在进行数据持久化之前，我们要了解 Ids4 是如何实现持久化的呢？ Ids4 默认是使用内存实现的 IClientStore、IResourceStore、IPersistedGrantStore 三个接口，对应的分别是 InMemoryClientStore、InMemoryResourcesStore、InMemoryPersistedGrantStore 三个方法，这显然达不到我们持久化的需求，因为都是从内存里提取配置信息，所以我们要做到 Ids4 配置信息持久化，就需要实现这三个接口，作为优秀的身份认证框架，肯定已经帮我们想到了这点啦，有个EFCore的持久化实现，GitHub地址 https://github.com/IdentityServer/IdentityServer4.EntityFramework

1、引用Dapper 2、创建DapperFactory类 public class DapperFactory { public static readonly string connectionString = ConfigurationManager.AppSettings["connection_string"]; public static OracleConnection CrateOracleConnection() { var connection = new OracleConnection(connectionString); connection.Open(); return connection; } } 3、创建测试类以及映射关系 public class SysUser { public string EmpID { get; set; } public string ID { get; set; } public string UserName { get; set; } public string RealName { get; set; } } [Serializable] public class SysUserMapping : ClassMapper<SysUser> { public SysUserMapping() { base