Dapper 基本使用

项目右键 Manage NuGet Packages for Solution 搜索Dapper -> Install

Base基类

  from:https://blog.csdn.net/kingcruel/article/details/52848950

龙生   27 Mar 2018
View Details

总结一下当下流行的几个技术名词

DDD 领域驱动设计 …… 是一种设计思想 CQRS 命令查询职责分离 …… 一种架构,其实就是程序层面的读写分离 IoC 控制反转 …… 一种设计模式,主要用到了反射技术 DI 依赖注入 …… IoC实现的过程就是DI

龙生   27 Mar 2018
View Details

CQRS架构简介

CQRS架构简介 前不久,看到博客园一位园友写了一篇文章,其中的观点是,要想高性能,需要尽量:避开网络开销(IO),避开海量数据,避开资源争夺。对于这3点,我觉得很有道理。所以也想谈一下,CQRS架构下是如何实现高性能的。 关于CQRS(Command Query Responsibility Segration)架构,大家应该不会陌生了。简单的说,就是一个系统,从架构上把它拆分为两部分:命令处理(写请求)+查询处理(读请求)。然后读写两边可以用不同的架构实现,以实现CQ两端(即Command Side,简称C端;Query Side,简称Q端)的分别优化。CQRS作为一个读写分离思想的架构,在数据存储方面,没有做过多的约束。所以,我觉得CQRS可以有不同层次的实现,比如: CQ两端数据库共享,CQ两端只是在上层代码上分离;这种做法,带来的好处是可以让我们的代码读写分离,更好维护,且没有CQ两端的数据一致性问题,因为是共享一个数据库的。我个人认为,这种架构很实用,既兼顾了数据的强一致性,又能让代码好维护。 CQ两端数据库和上层代码都分离,然后Q的数据由C端同步过来,一般是通过Domain Event进行同步。同步方式有两种,同步或异步,如果需要CQ两端的强一致性,则需要用同步;如果能接受CQ两端数据的最终一致性,则可以使用异步。采用这种方式的架构,个人觉得,C端应该采用Event Sourcing(简称ES)模式才有意义,否则就是自己给自己找麻烦。因为这样做你会发现会出现冗余数据,同样的数据,在C端的db中有,而在Q端的db中也有。和上面第一种做法相比,我想不到什么好处。而采用ES,则所有C端的最新数据全部用Domain Event表达即可;而要查询显示用的数据,则从Q端的ReadDB(关系型数据库)查询即可。 我觉得要实现高性能,可以谈的东西还有很多。下面我想重点说说我想到的一些设计思路: 避开资源争夺 秒杀活动的例子分析 我觉得这是很重要的一点。什么是资源争夺?我想就是多个线程同时修改同一个数据。就像阿里秒杀活动一样,秒杀开抢时,很多人同时抢一个商品,导致商品的库存会被并发更新减库存,这就是一个资源争夺的例子。一般如果资源竞争不激烈,那无所谓,不会影响性能;但是如果像秒杀这种场景,那db就会抗不住了。在秒杀这种场景下,大量线程需要同时更新同一条记录,进而导致MySQL内部大量线程堆积,对服务性能、稳定性造成很大伤害。那怎么办呢?我记得阿里的丁奇写过一个分享,思路就是当MySQL的服务端多个线程同时修改一条记录时,可以对这些修改请求进行排队,然后对于InnoDB引擎层,就是串行的。这样排队后,不管上层应用发过来多少并行的修改同一行的请求,对于MySQL Server端来说,内部总是会聪明的对同一行的修改请求都排队处理;这样就能确保不会有并发产生,从而不会导致线程浪费堆积,导致数据库性能下降。这个方案可以见下图所示: 如上图所示,当很多请求都要修改A记录时,MySQL Server内部会对这些请求进行排队,然后一个个将对A的修改请求提交到InnoDB引擎层。这样看似在排队,实际上会确保MySQL Server不会死掉,可以保证对外提供稳定的TPS。 但是,对于商品秒杀这个场景,还有优化的空间,就是Group Commit技术。Group Commit就是对多个请求合并为一次操作进行处理。秒杀时,大家都在购买这个商品,A买2件,B买3件,C买1件;其实我们可以把A,B,C的这三个请求合并为一次减库存操作,就是一次性减6件。这样,对于A,B,C的这三个请求,在InnoDB层我们只需要做一次减库存操作即可。假设我们Group Commit的每一批的size是50,那就是可以将50个减操作合并为一次减操作,然后提交到InnoDB。这样,将大大提高秒杀场景下,商品减库存的TPS。但是这个Group Commit的每批大小不是越大越好,而是要根据并发量以及服务器的实际情况做测试来得到一个最优的值。通过Group Commit技术,根据丁奇的PPT,商品减库存的TPS性能从原来的1.5W提高到了8.5W。 从上面这个例子,我们可以看到阿里是如何在实际场景中,通过优化MySQL Server来实现高并发的商品减库存的。但是,这个技术一般人还真的不会!因为没多少人有能力去优化MySQL的服务端,排队也不行,更别说Group Commit了。这个功能并不是MySQL Server自带的,而是需要自己实现的。但是,这个思路我想我们都可以借鉴。 CQRS如何实现避免资源竞争 那么对于CQRS架构,如何按照这个思路来设计呢?我想重点说一下我上面提到的第二种CQRS架构。对于C端,我们的目标是尽可能的在1s内处理更多的Command,也就是数据写请求。在经典DDD的四层架构中,我们会有一个模式叫工作单元模式,即Unit of Work(简称UoW)模式。通过该模式,我们能在应用层,一次性以事务的方式将当前请求所涉及的多个对象的修改提交到DB。微软的EF实体框架的DbContext就是一个UoW模式的实现。这种做法的好处是,一个请求对多个聚合根的修改,能做到强一致性,因为是事务的。但是这种做法,实际上,没有很好的遵守避开资源竞争的原则。试想,事务A要修改a1,a2,a3三个聚合根;事务B要修改a2,a3,a4;事务C要修改a3,a4,a5三个聚合根。那这样,我们很容易理解,这三个事务只能串行执行,因为它们要修改相同的资源。比如事务A和事务B都要修改a2,a3这两个聚合根,那同一时刻,只能由一个事务能被执行。同理,事务B和事务C也是一样。如果A,B,C这种事务执行的并发很高,那数据库就会出现严重的并发冲突,甚至死锁。那要如何避免这种资源竞争呢?我觉得我们可以采取三个措施: 让一个Command总是只修改一个聚合根 这个做法其实就是缩小事务的范围,确保一个事务一次只涉及一条记录的修改。也就是做到,只有单个聚合根的修改才是事务的,让聚合根成为数据强一致性的最小单位。这样我们就能最大化的实现并行修改。但是你会问,但是我一个请求就是会涉及多个聚合根的修改的,这种情况怎么办呢?在CQRS架构中,有一个东西叫Saga。Saga是一种基于事件驱动的思想来实现业务流程的技术,通过Saga,我们可以用最终一致性的方式最终实现对多个聚合根的修改。对于一次涉及多个聚合根修改的业务场景,一般总是可以设计为一个业务流程,也就是可以定义出要先做什么后做什么。比如以银行转账的场景为例子,如果是按照传统事务的做法,那可能是先开启一个事务,然后让A账号扣减余额,再让B账号加上余额,最后提交事务;如果A账号余额不足,则直接抛出异常,同理B账号如果加上余额也遇到异常,那也抛出异常即可,事务会保证原子性以及自动回滚。也就是说,数据一致性已经由DB帮我们做掉了。 但是,如果是Saga的设计,那就不是这样了。我们会把整个转账过程定义为一个业务流程。然后,流程中会包括多个参与该流程的聚合根以及一个用于协调聚合根交互的流程管理器(ProcessManager,无状态),流程管理器负责响应流程中的每个聚合根产生的领域事件,然后根据事件发送相应的Command,从而继续驱动其他的聚合根进行操作。 转账的例子,涉及到的聚合根有:两个银行账号聚合根,一个交易(Transaction)聚合根,它用于负责存储流程的当前状态,它还会维护流程状态变更时的规则约束;然后当然还有一个流程管理器。转账开始时,我们会先创建一个Transaction聚合根,然后它产生一个TransactionStarted的事件,然后流程管理器响应事件,然后发送一个Command让A账号聚合根做减余额的操作;A账号操作完成后,产生领域事件;然后流程管理器响应事件,然后发送一个Command通知Transaction聚合根确认A账号的操作;确认完成后也会产生事件,然后流程管理器再响应,然后发送一个Command通知B账号做加上余额的操作;后续的步骤就不详细讲了。大概意思我想已经表达了。总之,通过这样的设计,我们可以通过事件驱动的方式,来完成整个业务流程。如果流程中的任何一步出现了异常,那我们可以在流程中定义补偿机制实现回退操作。或者不回退也没关系,因为Transaction聚合根记录了流程的当前状态,这样我们可以很方便的后续排查有状态没有正常结束的转账交易。具体的设计和代码,有兴趣的可以去看一下ENode源代码中的银行转账的例子,里面有完整的实现。 对修改同一个聚合根的Command进行排队 和上面秒杀的设计一样,我们可以对要同时修改同一个聚合根的Command进行排队。只不过这里的排队不是在MySQL Server端,而是在我们自己程序里做这个排队。如果我们是单台服务器处理所有的Command,那排队很容易做。就是只要在内存中,当要处理某个Command时,判断当前Command要修改的聚合根是否前面已经有Command在处理,如果有,则排队;如果没有,则直接执行。然后当这个聚合根的前一个Command执行完后,我们就能处理该聚合根的下一个Command了;但是如果是集群的情况下呢,也就是你不止有一台服务器在处理Command,而是有十台,那要怎么办呢?因为同一时刻,完全有可能有两个不同的Command在修改同一个聚合根。这个问题也简单,就是我们可以对要修改聚合根的Command根据聚合根的ID进行路由,根据聚合根的ID的hashcode,然后和当前处理Command的服务器数目取模,就能确定当前Command要被路由到哪个服务器上处理了。这样我们能确保在服务器数目不变的情况下,针对同一个聚合根实例修改的所有Command都是被路由到同一台服务器处理。然后加上我们前面在单个服务器里面内部做的排队设计,就能最终保证,对同一个聚合根的修改,同一时刻只有一个线程在进行。 通过上面这两个设计,我们可以确保C端所有的Command,都不会出现并发冲突。但是也要付出代价,那就是要接受最终一致性。比如Saga的思想,就是在最终一致性的基础上而实现的一种设计。然后,基于以上两点的这种架构的设计,我觉得最关键的是要做到:1)分布式消息队列的可靠,不能丢消息,否则Saga流程就断了;2)消息队列要高性能,支持高吞吐量;这样才能在高并发时,实现整个系统的整体的高性能。我开发的EQueue就是为了这个目标而设计的一个分布式消息队列,有兴趣的朋友可以去了解下哦。 Command和Event的幂等处理 CQRS架构是基于消息驱动的,所以我们要尽量避免消息的重复消费。否则,可能会导致某个消息被重复消费而导致最终数据无法一致。对于CQRS架构,我觉得主要考虑三个环节的消息幂等处理。 Command的幂等处理 这一点,我想不难理解。比如转账的例子中,假如A账号扣减余额的命令被重复执行了,那会导致A账号扣了两次钱。那最后就数据无法一致了。所以,我们要保证Command不能被重复执行。那怎么保证呢?想想我们平时一些判断重复的操作怎么做的?一般有两个做法:1)db对某一列建唯一索引,这样可以严格保证某一列数据的值不会重复;2)通过程序保证,比如插入前先通过select查询判断是否存在,如果不存在,则insert,否则就认为重复;显然通过第二种设计,在并发的情况下,是不能保证绝对的唯一性的。然后CQRS架构,我认为我们可以通过持久化Command的方式,然后把CommandId作为主键,确保Command不会重复。那我们是否要每次执行Command前线判断该Command是否存在呢?不用。因为出现Command重复的概率很低,一般只有是在我们服务器机器数量变动时才会出现。比如增加了一台服务器后,会影响到Command的路由,从而最终会导致某个Command会被重复处理,关于这里的细节,我这里不想多展开了,呵呵。有问题到回复里讨论吧。这个问题,我们也可以最大程度上避免,比如我们可以在某一天系统最空的时候预先增加好服务器,这样可以把出现重复消费消息的情况降至最低。自然也就最大化的避免了Command的重复执行。所以,基于这个原因,我们没有必要在每次执行一个Command时先判断该Command是否已执行。而是只要在Command执行完之后,直接持久化该Command即可,然后因为db中以CommandId为主键,所以如果出现重复,会主键重复的异常。我们只要捕获该异常,然后就知道了该Command已经存在,这就说明该Command之前已经被处理过了,那我们只要忽略该Command即可(当然实际上不能直接忽略,这里我由于篇幅问题,我就不详细展开了,具体我们可以再讨论)。然后,如果持久化没有问题,说明该Command之前没有被执行过,那就OK了。这里,还有个问题也不能忽视,就是某个Command第一次执行完成了,也持久化成功了,但是它由于某种原因没有从消息队列中删除。所以,当它下次再被执行时,Command Handler里可能会报异常,所以,健壮的做法时,我们要捕获这个异常。当出现异常时,我们要检查该Command是否之前已执行过,如果有,就要认为当前Command执行正确,然后要把之前Command产生的事件拿出来做后续的处理。这个问题有点深入了,我暂时不细化了。有兴趣的可以找我私聊。 Event持久化的幂等处理 然后,因为我们的架构是基于ES的,所以,针对新增或修改聚合根的Command,总是会产生相应的领域事件(Domain Event)。我们接下来的要做的事情就是要先持久化事件,再分发这些事件给所有的外部事件订阅者。大家知道,聚合根有生命周期,在它的生命周期里,会经历各种事件,而事件的发生总有确定的时间顺序。所以,为了明确哪个事件先发生,哪个事件后发生,我们可以对每个事件设置一个版本号,即version。聚合根第一个产生的事件的version为1,第二个为2,以此类推。然后聚合根本身也有一个版本号,用于记录当前自己的版本是什么,它每次产生下一个事件时,也能根据自己的版本号推导出下一个要产生的事件的版本号是什么。比如聚合根当前的版本号为5,那下一个事件的版本号则为6。通过为每个事件设计一个版本号,我们就能很方便的实现聚合根产生事件时的并发控制了,因为一个聚合根不可能产生两个版本号一样的事件,如果出现这种情况,那说明一定是出现并发冲突了。也就是一定是出现了同一个聚合根同时被两个Command修改的情况了。所以,要实现事件持久化的幂等处理,也很好做了,就是db中的事件表,对聚合根ID+聚合根当前的version建唯一索引。这样就能在db层面,确保Event持久化的幂等处理。另外,对于事件的持久化,我们也可以像秒杀那样,实现Group Commit。就是Command产生的事件不用立马持久化,而是可以先积累到一定的量,比如50个,然后再一次性Group Commit所有的事件。然后事件持久化完成后,再修改每个聚合根的状态即可。如果Group Commit事件时遇到并发冲突(由于某个聚合根的事件的版本号有重复),则退回为单个一个个持久化事件即可。为什么可以放心的这样做?因为我们已经基本做到确保一个聚合根同一时刻只会被一个Command修改。这样就能基本保证,这些Group Commit的事件也不会出现版本号冲突的情况。所以,大家是否觉得,很多设计其实是一环套一环的。Group Commit何时出发?我觉得可以只要满足两个条件了就可以触发:1)某个定时的周期到了就可以触发,这个定时周期可以根据自己的业务场景进行配置,比如每隔50ms触发一次;2)要Commit的事件到达某个最大值,即每批可以持久化的事件个数的最大值,比如每50个事件为一批,这个BatchSize也需要根据实际业务场景和你的存储db的性能综合测试评估来得到一个最适合的值;何时可以使用Group Commit?我觉得只有是在并发非常高,当单个持久化事件遇到性能瓶颈时,才需要使用。否则反而会降低事件持久化的实时性,Group Commit提高的是高并发下单位时间内持久化的事件数。目的是为了降低应用和DB之间交互的次数,从而减少IO的次数。不知不觉就说到了最开始说的那3点性能优化中的,尽量减少IO了,呵呵。 Event消费时的幂等处理 CQRS架构图中,事件持久化完成后,接下来就是会把这些事件发布出去(发送到分布式消息队列),给消费者消费了,也就是给所有的Event Handler处理。这些Event Handler可能是更新Q端的ReadDB,也可能是发送邮件,也可能是调用外部系统的接口。作为框架,应该有职责尽量保证一个事件尽量不要被某个Event Handler重复消费,否则,就需要Event Handler自己保证了。这里的幂等处理,我能想到的办法就是用一张表,存储某个事件是否被某个Event Handler处理的信息。每次调用Event Handler之前,判断该Event Handler是否已处理过,如果没处理过,就处理,处理完后,插入一条记录到这个表。这个方法相信大家也都很容易想到。如果框架不做这个事情,那Event Handler内部就要自己做好幂等处理。这个思路就是select if not exist, then handle, and at last insert的过程。可以看到这个过程不像前面那两个过程那样很严谨,因为在并发的情况下,理论上还是会出现重复执行Event Handler的情况。或者即便不是并发时也可能会造成,那就是假如event handler执行成功了,但是last insert失败了,那框架还是会重试执行event handler。这里,你会很容易想到,为了做这个幂等支持,Event Handler的一次完整执行,需要增加不少时间,从而会最后导致Query Side的数据更新的延迟。不过CQRS架构的思想就是Q端的数据由C端通过事件同步过来,所以Q端的更新本身就是有一定的延迟的。这也是CQRS架构所说的要接收最终一致性的原因。 关于幂等处理的性能问题的思考 关于CommandStore的性能瓶颈分析 大家知道,整个CQRS架构中,Command,Event的产生以及处理是非常频繁的,数据量也是非常大的。那如何保证这几步幂等处理的高性能呢?对于Command的幂等处理,如果对性能要求不是很高,那我们可以简单使用关系型DB即可,比如Sql Server, MySQL都可以。要实现幂等处理,只需要把主键设计为CommandId即可。其他不需要额外的唯一索引。所以这里的性能瓶颈相当于是对单表做大量insert操作的最大TPS。一般MySQL数据库,SSD硬盘,要达到2W […]

龙生   27 Mar 2018
View Details

TPS及计算方法

TPS (transaction per second)代表每秒执行的事务数量,可基于测试周期内完成的事务数量计算得出。例如,用户每分钟执行6个事务,TPS为6 / 60s = 0.10 TPS。同时我们会知道事务的响应时间(或节拍),以此例,60秒完成6个事务也同时代表每个事务的响应时间或节拍为10秒。 利特尔法则  (Little’s law): 该法则由麻省理工大学斯隆商学院(MIT Sloan School of Management)的教授John Little﹐于1961年所提出与证明。它是一个有关提前期与在制品关系的简单数学公式,这一法则为精益生产的改善方向指明了道路。 利特尔法则的公式描述为:Lead Time(产出时间)= 存货数量×生产节拍     或     TH(生产效率)= WIP(存货数量)/ CT(周期时间) P.S: 稍后我们会列出负载模型中利特尔法则的应用公式。 我们通过2个示例来看一下此法则是如何在生产环境中发生作用的。 例1:假定我们所开发的并发服务器,并发的访问速率是:1000客户/分钟,每个客户在该服务器上将花费平均0.5分钟,根据little’s law规则,在任何时刻,服务器将承担1000×0.5=500个客户量的业务处理。假定过了一段时间,由于客户群的增大,并发的访问速率提升为2000客户/分钟。在这样的情况下,我们该如何改进我们系统的性能? 根据little’s law规则,有两种方案: 第一:提高服务器并发处理的业务量,即提高到2000×0.5=1000。 或者 第二:减少服务器平均处理客户请求的时间,即减少到:2000×0.25=500。 例2:假设你排队参观某个风景点,该风景点固定的容纳人数是:60人。每个人在该风景点停留的平均时间是:3分钟。假设在你的前面还排有20个人,问:你估计你大概等多少时间才能进入该风景点。 答案:1小时(3×20=60),和该景点固定的容纳人数无关。 为了通过利特尔法则研究负载模型,我们就先要了解两个因子:响应时间(Response time)和节拍(Pacing)。实际上节拍会超越响应时间对TPS的影响。 示例1:节拍0秒,思考时间0秒 用户执行5个事务并且每个事务的响应时间是10秒,需要花费50秒完成5个事务,即5/50=0.1 TPS (这里TPS是由响应时间控制)。 示例2:速率15秒,思考时间0秒 用户执行5个事务且每个事务的响应时间是10秒,但实际由于节拍大于响应时间,所以它优于响应时间控制了事务发生的频率。完成5个事务需要5*15 = 75秒,产生5/75=0.06667 TPS。 在第二个示例中,平均响应时间小于节拍15秒,需要75秒完成5个迭代,产生了0.06667 TPS。 上面两个例子中我们假设思考时间为0秒。如果思考时间为2秒,总时间仍是75秒完成5个迭代,产生0.06667 TPS。 节拍为0秒,则     用户数 = TPS * ( 响应时间 + 思考时间 ) 节拍不为0秒且大于响应时间与思考时间的和,则     用户数 = TPS * (速率) 事实上TPS是事务在w.r.t时间的速率,所以也被称为吞吐量(throughput)。 所以利特尔法则在负载模型中解释为:系统内平均用户数 = 平均响应时间 * 吞吐量 N = ( R + Z ) * X N, 用户数 R, 平均响应时间(也可能是速率) Z, […]

龙生   27 Mar 2018
View Details

轻量级高性能ORM框架:Dapper高级玩法

Dapper高级玩法1: 数据库中带下划线的表字段自动匹配无下划线的Model字段。 Dapper.DefaultTypeMap.MatchNamesWithUnderscores = true; 备注: 这个对使用Mysql数据库的朋友最有帮助,因为Mysql默认都是小写,一般字段都带下划线,比如:user_name之类。   具体效果如下演示 1,首先创建一张表并插入数据 2,创建Model模型

    3,扩写抽取数据逻辑代码. select * from [user]

    4,无MatchNamesWithUnderscores设置时的数据抽取 没有绑定成功?? 这是因为用了Select * from的缘故,取出来的字段是带下划线的与Model的字段不匹配。   5,设置MatchNamesWithUnderscores再次数据抽取

  数据绑定成功。 就一句Dapper.DefaultTypeMap.MatchNamesWithUnderscores = true,让我们少写了不少AS语句。   Dapper高级玩法2: 法力无边的Query,由于带有Function功能,可以自由设置模型绑定逻辑。   1,创建两张有关联的表,并填入数据。 2,抽取user和它关联的role数据。 select 1 as table1,T1.*,1 as table2,T2.* from [user] T1 inner join [role] T2 on T1.role_id = T2.role_id 扩展方法:

  使用:

  成功取到数据。 splitOn解释:模型绑定时的字段分割标志。table1到table2之间的表字段绑定到User,table2之后的表字段绑定到Role。   3,特殊Function逻辑。比如抽取role_id对应的user一览。 select 1 as table1,T1.*,1 as table2,T2.* from [role] T1 left join [user] T2 on T1.role_id = T2.role_id 外部定义了一个字典类型,Query内部模型绑定的时候每次调用Function函数,Function函数中将数据添加到外部字典中,这在复杂数据处理时很有用。

  […]

龙生   27 Mar 2018
View Details

轻量级ORM框架——第一篇:Dapper快速学习

我们都知道ORM全称叫做Object Relationship Mapper,也就是可以用object来map我们的db,而且市面上的orm框架有很多,其中有一个框架 叫做dapper,而且被称为the king of ORM。   一:为什么选择Dapper 1. 性能优越: 其实在各大网站上,我们大概都会看到这样的一个对比效果图,在超过500次poco serialization的过程中所表现的性能,我们发现dapper是第二名, 当然第一名谁也无法超越,越底层的当然久越快,同时也就越麻烦。就好像谁能超过“01代码”呢???   2. 支持多数据库 支持多数据库的本质是因为Dapper是对IDBConnection接口进行了方法扩展,比如你看到的SqlMapper.cs,一旦你这样做了,我们也知道, SqlConnection,MysqlConnection,OracleConnection都是继承于DBConnection,而DBConnection又是实现了IDBConnection的接口,对吧。。。   二:安装Dapper install dapper的方式通常有两种:   1. 通过nuget进行安装 如果你不知道怎么用nuget进行安装,或者不知道install-package是什么,可以在browser上找一下,比如下面这样:   然后我们copy到package console 试试看。     2. 在github上获取源码。 为什么要获取源码,是因为用ilspy调试dapper的源码太费劲了,毕竟现在都是异步编程了,从ilspy中看都是匿名方法很多都无法渗透,废话不多 说,我们只要把Dapper文件夹拉出来然后copy到我们的solution就可以了,如下图:   三:快速CURD操作 其实对数据库的操作莫过于CURD,在进行操作之前我们再配一个Users表。   1. 配置Users表

  2. Insert操作 通常来说,有两种insert操作: <1>单条insert操作 这是一个简单的参数化insert,而且还可以塞入匿名类型,对吧,跟原始的SqlParameter相比,是不是简单的多???

  <2> InsertBulk操作 既然是Bulk操作,那肯定就是批量插入了,我们要做的就是将上面这个 ”匿名对象" 变成 ”匿名对象集合“ 就可以了。。。为了方便操作,这里定义 一个Users类,比如下面这样。。。

  2. Query操作 其实在Dapper在query上提供的的文章太多了。。。这篇我们就按照最简单的参数化查询就好了。。。比如我要找到username=jack的记录,如下:

  图上的亮点就在于能够自动化mapper到我们object上面来,这是我们DataReader所不能办到的,对吧~~   3.update操作 这种操作方式,我们还是使用Execute方法来实现,和insert是一种套路的哦。   4. delete操作 这里我还是采用参数化的形式来删除UserID=10这条记录,方式如下:   最终sql的table展示如下,可以看到已经正确的修改了UserID=11的记录,删除了UserID=10的record。。。。当然Dapper好玩的地方多着呢, 这篇只是一个入门而已。。。希望本篇对大家有帮助~~~

龙生   27 Mar 2018
View Details

dapper使用

访问量不大的项目我都是用EF写数据库操作,因为EF除了速度上慢以外,但开发效率极快,省略了很多sql写法,并能很方便的调用外键、集合等信息,用EF写项目最爽的事。不过有些项目网站要考虑运行速度,这时不得不用其它的ORM框架,我常用dapper,因为它效果快,而且写sql非常灵活,接下来面写一些方法看看dapper的使用 1、连接语句 var conn = new SqlConnection(ConfigurationManager.ConnectionStrings["SqlDiagnosticsDb"].ConnectionString); 使用dapper不需要考虑conn是否连接,在执行dapper时自行判断 open状态,如果没有打开它会自己打开。 2、insert

book类中有name属性,就可以这样方便去写,当然也可以写成

3、update

4、 delete

5、query

6、 传统sql in (1,2,3) 用dapper就这样写

在dapper因为安全性,不能直接用sql接接    要采用参数化, 7、批量插入

也可以直接写入一个集合

这里users是一个user表的对象集合,可一次把集合中的所有数据插入到数据表中。 8、多表查询

多表联合查询是比较麻烦一些,到现在不是完全明白,多看几个例子

Post类和User类,它们存在外键, conn.Query返回的类型是最后一个参数Post, 其中Post中有一属性Owner是User对象,在(post, user)=>lamda中指定了Owner值,上边的代码中的splitOn是ID,运行时,会从查询结果所有字段列表的最后一个字段开始进行匹配,一直到找到Id这个字段(大小写忽略),找到的第一个ID字段匹配User类的ID属性,那么从ID到最后一个字段都属于User,ID以前的字段都被影射到Post, 通过 (post, user) => {return post;},把两个类的实例解析出来。 9、三表查询,一个是关联主键表(单个对象),一个是关联外键表(集合)。

 

 

 

  注意这里的对象和集合的获取方法:u.Movies = m; u.MyTYC.Add(t); 10、多结果查询

  再来一个

  11、如果某一代码中多次操作数据库,可以把conn设置为打开,最后时再close, 比如:

  from:https://www.cnblogs.com/lunawzh/p/6607116.html

龙生   27 Mar 2018
View Details

图解WebGL&Three.js工作原理

一、我们讲什么? 我们讲两个东西: 1、WebGL背后的工作原理是什么? 2、以Three.js为例,讲述框架在背后扮演什么样的角色?   二、我们为什么要了解原理? 我们假定你对WebGL已经有一定了解,或者用Three.js做过了一些东西,这个时候,你可能碰到了这样一些问题: 1、很多东西还是做不出来,甚至没有任何思路; 2、碰到bug无法解决,甚至没有方向; 3、性能出现问题,完全不知道如何去优化。 这个时候,我们需要了解更多。   三、先了解一个基础概念 1、什么是矩阵? 简单说来,矩阵用于坐标变换,如下图: 2、那它具体是怎么变换的呢,如下图: 3、举个实例,将坐标平移2,如下图:   如果这时候,你还是没有理解,没有关系,你只需要知道,矩阵用于坐标变换。   四、WebGL的工作原理 4.1、WebGL API 在了解一门新技术前,我们都会先看看它的开发文档或者API。 查看Canvas的绘图API,我们会发现它能画直线、矩形、圆、弧线、贝塞尔曲线。 于是,我们看了看WebGL绘图API,发现: 它只能会点、线、三角形?一定是我看错了。 没有,你没看错。 就算是这样一个复杂的模型,也是一个个三角形画出来的。   4.2、WebGL绘制流程 简单说来,WebGL绘制过程包括以下三步: 1、获取顶点坐标 2、图元装配(即画出一个个三角形) 3、光栅化(生成片元,即一个个像素点) 接下来,我们分步讲解每个步骤。   4.2.1、获取顶点坐标 顶点坐标从何而来呢?一个立方体还好说,如果是一个机器人呢? 没错,我们不会一个一个写这些坐标。 往往它来自三维软件导出,或者是框架生成,如下图: 写入缓存区是啥? 没错,为了简化流程,之前我没有介绍。 由于顶点数据往往成千上万,在获取到顶点坐标后,我们通常会将它存储在显存,即缓存区内,方便GPU更快读取。   4.2.2、图元装配 我们已经知道,图元装配就是由顶点生成一个个图元(即三角形)。那这个过程是自动完成的吗?答案是并非完全如此。 为了使我们有更高的可控性,即自由控制顶点位置,WebGL把这个权力交给了我们,这就是可编程渲染管线(不用理解)。 WebGL需要我们先处理顶点,那怎么处理呢?我们先看下图: 我们引入了一个新的名词,叫“顶点着色器”,它由opengl es编写,由javascript以字符串的形式定义并传递给GPU生成。 比如如下就是一段顶点着色器代码: 1 2 3 4 attribute vec4 position; void main() {   gl_Position = position;  } attribute修饰符用于声明由浏览器(javascript)传输给顶点着色器的变量值; position即我们定义的顶点坐标; gl_Position是一个内建的传出变量。 这段代码什么也没做,如果是绘制2d图形,没问题,但如果是绘制3d图形,即传入的顶点坐标是一个三维坐标,我们则需要转换成屏幕坐标。 比如:v(-0.5, 0.0, 1.0)转换为p(0.2, -0.4),这个过程类似我们用相机拍照。   4.2.2.1、顶点着色器处理流程 回到刚才的话题,顶点着色器是如何处理顶点坐标的呢? 如上图,顶点着色器会先将坐标转换完毕,然后由GPU进行图元装配,有多少顶点,这段顶点着色器程序就运行了多少次。 你可能留意到,这时候顶点着色器变为: 1 2 3 4 5 attribute vec4 position; uniform mat4 […]

龙生   26 Mar 2018
View Details

Web 前端开发精华文章推荐(jQuery、HTML5、CSS3)【系列十二】

2012年12月12日,【《Web 前端开发人员和设计师必读文章》系列十二】和大家见面了。梦想天空博客关注 前端开发 技术,分享各种增强网站用户体验的 jQuery 插件,展示前沿的 HTML5 和 CSS3 技术应用,推荐优秀的 网页设计 案例,共享精美的设计素材和优秀的 Web 开发工具,希望这些精心推荐的文章能够帮助到您。 jQuery 插件和教程 精心挑选:精美的 jQuery 加载动画和进度条插件 精心挑选:10款基于 jQuery 的图片360度旋转插件 精心挑选:几款实用的 jQuery 全景图片展示插件 精心挑选:推荐6套精美的免费 jQuery UI 主题 精心挑选:12款 JavaScript 日历和时间选择插件 精心挑选:12款优秀 jQuery Ajax 分页插件和教程 精心挑选:23款美轮美奂的 jQuery 图片特效插件 精心挑选:10款实用的 jQuery Tab 切换插件和教程 精心挑选:15款优秀 jQuery 文本特效插件和教程 精心挑选:33个优秀的 jQuery 图片展示插件分享 HTML5 & CSS3 应用 Web 前沿:展示一组极其绚丽的 CSS3 效果 未来的Web:让你惊叹的 Chrome 实验项目 推荐十款非常优秀的 HTML5 在线设计工具 35款优秀的基于 HTML5 开发的网页游戏 你可能不知道的5个功能强大的 HTML5 API Web前沿:CSS3 在网页设计中的20佳惊艳应用 Web技术前沿:那些让人惊叹的 CSS3 应用演示 推荐35款非常精致的 CSS3 和 HTML5 网页模板 推荐十款精心挑选的在线 CSS3 代码生成工具 推荐几份能够帮助你学习 CSS3 的实用帮助手册 精美网站模板 推荐10套精美的免费网站后台管理系统模板 12款高质量的免费 HTML 网页模板下载 12款非常漂亮的免费 CSS 网页模板下载 30款精美的国外企业网站模板 PSD 免费下载 分享20款精美的免费 Flash […]

龙生   26 Mar 2018
View Details
1 200 201 202 432