因为老板的一句话公司项目需要迁移到.NetCore，但是以前同事用的ORM不支持.NetCore开发过程也遇到了各种坑，插入条数多了也特别的慢，导致系统体验比较差好多都改写Sql实现。
所以我打算找一款
性能比较好
功能比较完善
方便以后可以切换数据库（经过我对老板的了解这个功能非常重要）
并且要有一定用户基础的ORM
参赛ORM
能够参赛的ORM必须要有以下个条件
第一、功能方面要比较完善
第二、Github需要有一定人气并且最近有更新
第三、支持多种数据库少写Sql，方便以后
筛选结果：
1、EFCore
2、Dapper+扩展
3、SqlSugarCore
4、NhibernateCore
5、PetaPoco
第一轮淘汰赛我们比人气&功能
经过对这几个ORM的初步了解，对功能方面和人气方面进行了初步评分
1、EFCore人气10，功能10
2、Dapper+扩展人气10，功能9
3、SqlSugarCore人气7，功能10
4、NhibernateCore人气7，功能10
5、PetaPoco人气6，功能6
经过第一轮帅选，我淘淘汰了PetaPocoORM
最重要的是这个ORM定位比较尴尬，功能一般并且扩展插件也比较稀少。现有功能以拼Sql为主满足不了我以后切换数据库的需求，第一轮淘态。
第一轮得分排名
1、EFCore胜出
2、Dapper+扩展胜出
3、SqlSugarCore，NhibernateCore胜出
4、PetaPoco淘汰
第二轮淘汰赛我们比易用性
写太牛逼的功能并不是我们所考虑的，需要上手快好用，于是我针对项目中几个需求点进行了上手测试，并给出了评分
1、EFCore10轻松满足
3、SqlSugarCore10轻松满足
4、NhibernateCore1完全不会用
第二轮得分排名
1、EFCore，SqlSugarCore胜出
3、NhibernateCore淘汰
能够通过精心挑选并且进入前3名，相信这3个ORM都有他们独自的魅力
第三轮淘汰赛我们比性能
经过对批量插入、单条插入、批量更新、单条更新、条件查询、多选删除等几种常用场景的并发测试
我意外的发现SqlSugar性能比Dapper更加的优秀，EFCore垫底
第三轮得分排名
1、SqlSugarCore胜出
3、EFCore淘汰
通过上面各种环节我们可以发现，我都会淘汰每场比赛表现最差者，因为我想找一个比较平衡的ORM用于项目，不想有短腿。
决赛我们比大家的建议
目前Dapper+扩展和SqlSugarCore这2个ORM是最适合我们的团队的，同事之间也各有说词,暂且平手吧。明天我们公司会在进行讨论。写个博文让大家给给建议，进行最终定夺。
下面是这2款ORM地址：
Dapper
SqlSugar
查询在应用程序中很重要，花样也特别多，不同得业务需求需要不同的查询条件，还要支持and、or……事实上也确实如此，程序中有N多个查询类，并且很可能其中有多个类查询同一张表，所以特别想弄一个通用的查询类。
前几天也是因为讨论有关查询的问题，想到了一个点子觉得可行，最近就抓紧实现了一下来验证想法的可行性……
思路：其实查询类很简单，无非就是你要查询哪个字段—字段名称（Key）、你想搜索的值—字段值（Value）、以及如何进行比较—查询类型（QueryType），这是单个查询条件（之后都叫做查询因子，不知道合适不合适，也是突然间想起来的），如果是多个条件，弄了一个集合就是好了，问题就在于这些查询因子之间的关系（and、or）……既然叫做查询因子，这个集合我们不管他们之间的关系，只是简单的查询因子的集合，我们在弄一个字段来存储他们之间的关系，这里暂时叫做逻辑表达式，例如：((a|b)&c)|((a&b&d)|e)，最后我就解析这个表达式就可以了，a、b、c、d、e只要在集合中找到具体的哪个查询因子就可以了，就是这样了。说通用查询类有点惭愧，目前只是在Mongodb下弄了一个简单的实现（重点是思路了，嘿嘿），因为项目上用的是Mongodb所以先实现的肯定是他了，其他的数据库同理……
1、找到最后一个“(”，之后寻找与之匹配的“)”，处理这对圆括号中的简单表达式，这里是a&b&d，处理完之后将结果放在一个字典之中
2、参照1的顺序再次处理表达式((a|b)&c)|(1|e)，这次处理1|e，字典中添加一项<2,filter2>，字符串变为((a|b)&c)|2
3、处理a|b，字典中添加一项<3,filter3>，字符串变为(3&c)|2
4、处理3&c，字典中添加一项<4,filter4>，字符串变为4|2
5、至此，圆括号已不再，只是简单的表达式，这就简单了
记录一下代码
类库方式实现：
这个功能需求比较简单，就是想在网页端显示实时天气数据。
解决方案：
第二种：既然方便的方式用不了，那么只能自己去寻找另一种的解决方案了；获取实时天气的步骤我给分了两步，第一步先获取用户的所在地，第二步根据所在地获取实时天气数据。
跨域的问题：
先在这里把跨域的问题提一下吧，js的ajax功能为了安全性考虑，只允许ajax访问相同域名下的接口，其他网站是不允许访问的；虽说ajax有jsonp的跨域请求，但是也得要求被访问的接口支持jsonp的数据格式返回（jsonp也是有一定的数据解析格式的），然而本文提到的接口基本上都是返回html或者字符串，是不符合jsonp数据解析的，因此这里需要后台来进行代理请求（就是js访问自己的后台，然后后台进行一次web请求而已）。
第一种：
第二种：
varreturnCitySN={"cip":"","cid":"370100","cname":"山东省济南市"};调用方式是在html页里面引用就好，也不必再考虑跨域的问题，而且在js里面也可以直接使用returnCitySN这个对象（object）。
使用的是后台来进行代理请求
这样就能根据上面获取对应的城市代码了，以济南（101120101）为例
后台代码如下：
到此为止我们终于获取到了用户所在地的实时天气数据了，返回前台js（同样使用eval(result)函数处理下返回的字符串就可以了）后怎么展示就不是本章的重点了，可以随便前端折腾。
总的来说就是适用后台来进行代理请求
特别注意，上述接口可能会过期失效，到时留言，我若看到会进行更新
在任何开发前都需要对要开发的东西有一定的了解、准备；
环境搭建：
1、新建项目，这里我们选择2d项目与TypeScript项目，由于小程序的游戏包的大小限制，在我掌握控制资源大小能力的时候，我选择了较为简单的2d项目
2、项目结构：1为项目的入口文件，相当于Main文件，至于为什么是入口文件，下面会提到；2为引用的代码资源，里面封装了2d项目必要的封装类；3为项目的场景资源文件，包括音频、视频、图片等游戏需要的资源；
3、bin文件夹：此文件夹是编译之后运行的文件夹，比较重要，下面来做详细介绍；
事实上，虽然我们在使用TypeScript开发小游戏，但是最后还是会编译为JavaScript文件，通过执行JavaScript文件来运行小游戏，只是使用TypeScript会比JavaScript开发的更加严谨一些，若你的JavaScript很强，那么也可尝试使用JavaScript来编写；
4、项目编写：项目的大体结构与编译了解的差不多之后，便开始编写我们自己的小程序——俄罗斯方块了，开发过程略，反正就是api的使用，这个在官网有这不少的案例与代码；
首先将以前的代码、资源文件删除掉，然后建立自己的工程，在发布之前，我将index.html文件中没有使用的js引用注释掉
5、发布，选择发布平台，先来个简单的发布吧，不包含版本控制之类的；发布之后，我们会得到一些文件，其实libs这个文件夹并没有多少用的，虽说里面有编译之后的封装文件，但是项目实际运行的所有代码都被LayaIDE自动压缩到code.js文件中，因此，libs文件夹可以删掉，为了减少游戏包体积嘛；还有一个不怎么好的消息，那就是，上面我说的资源文件夹assets是没有被发布出来的，我也没弄清楚怎么回事，只能手动拷贝出来，并且找到code.js文件中的引用路径并修改正确；
下一步目标：
1、学会使用分包加载游戏，更大的游戏包带来更好的游戏（虽说最多8M）；