dapper

目录 [LINQ2Dapper]最完整Dapper To Linq框架(一)---基础查询 [LINQ2Dapper]最完整Dapper To Linq框架(二)---动态化查询 [LINQ2Dapper]最完整Dapper To Linq框架(三)---实体类关系映射 [LINQ2Dapper]最完整Dapper To Linq框架(四)---Linq和SQL并行使用 [LINQ2Dapper]最完整Dapper To Linq框架(五)---查看Linq实际执行的SQL [LINQ2Dapper]最完整Dapper To Linq框架(六)---多表联合与匿名类型返回 [LINQ2Dapper]最完整Dapper To Linq框架(七)---仓储模式 [LINQ2Dapper]最完整Dapper To Linq框架(八)---导航属性 1.多表联合查询 默认情况下Where,Get,ToList,PageList等函数只支持单表操作， 如 var comment = conn.QuerySet<Comment>() .Where(x => x.Id.NotIn(new int[] { 1, 2, 3 }) && x.SubTime.AddMinutes(50) < DateTime.Now.AddDays(-1) && x.Type.IsNotNull()) .ToList(

此框架是Dapper的扩展，效率优于EntityFramwork，并且支持.NetFramework和.NetCore框架 支持.net framework4.5.1,.net core2.0及以上,更低版本适配如.netFramework4.0及以下请加群下载 支持Mssql,Oracle,Mysql等数据库 应用层需要引用包Kogel.Dapper.Extension.MsSql(如果数据库是Oracle则引用Kogel.Dapper.Extension.Oracle),Nuget上可以下载安装。 或者使用Nuget命令添加包 Install-Package Kogel.Dapper.Extension.MsSql 　 目录 [LINQ2Dapper]最完整Dapper To Linq框架(一)---基础查询 [LINQ2Dapper]最完整Dapper To Linq框架(二)---动态化查询 [LINQ2Dapper]最完整Dapper To Linq框架(三)---实体类关系映射 [LINQ2Dapper]最完整Dapper To Linq框架(四)---Linq和SQL并行使用 [LINQ2Dapper]最完整Dapper To Linq框架(五)---查看Linq实际执行的SQL [LINQ2Dapper]最完整Dapper To Linq框架(六)--

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个请求完整调用链可能如下图所示： 　　随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下： 　　随着业务规模不断增大、服务不断增多以及频繁变更的情况下，面对复杂的调用链路就带来一系列问题： 如何快速发现问题？ 如何判断故障影响范围？ 如何梳理服务依赖以及依赖的合理性？ 如何分析链路性能问题以及实时容量规划？ 　　 　　而链路追踪的出现正是为了解决这种问题，它可以在复杂的服务调用中定位问题，还可以在新人加入后台团队之后，让其清楚地知道自己所负责的服务在哪一环。 　　除此之外，如果某个接口突然耗时增加，也不必再逐个服务查询耗时情况，我们可以直观地分析出服务的性能瓶颈，方便在流量激增的情况下精准合理地扩容。 　　 什么是链路追踪 　　 　　“链路追踪”一词是在 2010 年提出的，当时谷歌发布了一篇 Dapper 论文： Dapper

Sleuth+Zipkin用来实现分布式系统的链路追踪。 Sleuth组件用于日志埋点、记录链路数据，Zipkin组件用于展示链路数据。 Sleuth的使用 （1）创建消费者、提供者时勾选Spring Cloud Tracing -> Sleuth 也可以手动添加依赖： < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-sleuth </ artifactId > </ dependency > （2）在消费者、提供者处理业务的类中添加成员变量 //使用的是 slf4j的日志，不要导错了 private final Logger logger = LoggerFactory.getLogger( this .getClass()); 在处理业务的方法中（消费者调用提供者、提供者处理业务的方法中），输出日志 logger.info("正在执行user-service的findOrdersByUserId方法，调用服务order-service"); 内容根据需要修改。 Sleuth输出的日志往往是空的，只输出服务名：[order-service,,,] 第（2）步是为了解决此问题，使Sleuth输出的日志有内容。 [order

框架采用dotnetcore+vue+elementUI 前后端分离，并且支持前端、后台代码业务动态扩展，框架内置了一套有着20多种属性配置的代码生成器，可灵活配置生成的代码，代码生成器界面配置完成即可生成单表/主从表的增、删、改、查、导入、导出、上传、审核基础功能。只需要简单了解即可上手开发 框架基础功能已构建完成，可直接上手开发功能 Vol.WebApi类库可独立用于restful api服务单独部署,用于其他系统单独提供接口,直接上手编写业务代码即可。 Vue+Vol.WebApi 可用于现有框架前后端分离进行开发 Vol.Web类库可用于传统MVC+Razor方式进行项目开发 Vol.Builder类库可作为一个独立的代码生成器,可生成cshtml页面、Vue页面、Model文件、Service与Repository.cs业务处理代码类 可作为一个独立站点来发布静态html网页. 可直接用于H5移动App开发 H5开发看这里 框架特点 支持前端、后台基础业务代码动态扩展，可在现有框架增、删、改、查、导入、导出、审核基础业务上扩展复杂的业务代码 基本业务全部由框架完成，上手即可对基础业务以外的代码进行扩展 上手简单，需要.net core2.1、VsCode mysql/sqlservcer 2012、redis(可选) 及以上版本的开发环境 学习成本低

　　在实际的项目中，除了集成ABP框架的EntityFrameworkCore以外，在有些特定的场景下不可避免地会使用一些SQL查询语句，一方面是由于现在的EntityFrameworkCore2.X有些问题没有解决，另外一方面是基于性能方面的考虑，在了解本篇内容之前，首先还是来看看 官方文档 来给出的说明。 　　按照官方的介绍整体可以分为下面的步骤：1 安装依赖包。2 添加DependsOn属性标签。3 Entity to Table Mapping。 4 Usage 通过上面的4个步骤我们就能够正常在Asp.Net Core项目中使用ABP Dapper了，下面我们就具体的过程来做进一步的说明。 　　 一 安装包依赖 　　这个不做过多的解释，通过Nuget 包管理器或者通过程序包管理控制台来添加Abp.Dapper的引用，在我们实际的项目中整个类库的结构如下图所示，包含Dapper和EntityFrameworkCore两种方案。 图一 项目结构 　　二 添加DependsOn属性标签 　 　后面我们就需要在我们当前类库项目中唯一的SalesDataModule中来做一些初始化和添加DependsOn标签的操作了。 [DependsOn(typeof(AbpZeroCoreEntityFrameworkCoreModule))] [DependsOn(typeof

　　最近研究了下ORM工具。总结一下。 　　之前有个小项目基于.Net40的WinForm。升级改造，想用ORM，由此引起。 　　第一选择是SqlSugar，国内团队制作，好用的很，但是.Net最低支持到4.5，而.Net45是不能在WinXP下运行，故可惜的放弃掉。 　　然后，找能在.Net40下运行的ORM，DosORM进入视野，但是发现有缺点，DosORM需要Model层都继承Entity类，而这个类在ORM.dll里，这样Model层将和ORM耦合，非常不好。而且DosTools工具生成的Model层，要求set里有onchange函数，而且还有内嵌类用于字段描述，简单的POCO，DosORM无法Update操作，造成Model层不干净。不佳。 　　转而，又延伸到Dapper，发现不错，1.52以下支持可以.Net40，对Model层简单set，get即可，无依赖，干净。缺点是它的CUDR需要写一些SQL，感觉不好，但是有个Dapper.SimpleCUDR的项目，引用后，可以支持简单泛型写法。那就选他了。其实在普通项目对DB层的需要，就是对单表的增删改查，多表的左连接查询，多表的事务更新，没有特别复杂的需求。 　　项目层次是，UI层引用Service层。Service层引用DB层。Model是独立的。DB层里包含Dapper和数据库连接器。Service层里有Dto

[toc] 前言 后端开发最常打交道的就是数据库了（静态网站靠边），上一篇 net core Webapi基础工程搭建（五）——缓存机制 ，缓存就是为了减少数据库的读操作，不过什么访问都是会耗时的，拿空间（内存）换时间对用户体验来说是惯用手段，后续介绍界面操作的时候再说用户体验。 SqlSugar 当然你可以用EF（太重，扩展性相对差，但不可否认基本上涵盖范围够广），也可以用Dapper（这个我之前头一回鼓捣net core的时候用的是Dapper），或者自己基于原生去写数据库的操作，都Ok，但是如果有造好的轮子，对于我们来说用就行了，可以深入理解但对于常规开发来说，CV大法是最好的（新手向）， SqlSugar 的 文档地址 。 之前的工程在最初创建的时候，没有创建完整，因为当时不操作数据层，所以偷个懒，这次一并创建，具体过程不再赘述 ，同 April.Util 工程的创建一致，都是类库项目，新建 April.Service ， April.Entity 。 好了，我们在Service与Entity项目中通过NuGet包引入 sqlSugarCore ，至于原因前面也说过 net core Webapi基础工程搭建（四）——日志功能log4net 。 这里应该不需要再图文介绍引入了，如果不清楚，也可以去上面的链接查看NuGet的引入方法。 引入完成后