ORM之煬,打造自已獨特的開發框架CRL

ORM一直是長久不衰的話題,各類重複造輪子的過程一直在進行,輪子都同樣是圓的,你的又有什麼特色呢?

CRL這個輪子造了好多年,功能也愈來愈標準完備,在開發過程當中,解決了不少問題,先上一張腦圖描述CRL的功能

開發框架的意義在於

• 開發更標準,更統一,不會由於不一樣人寫的代碼不同
• 開發效率更高,無需從新造輪子,重複無用的代碼,同時簡化開發流程
• 運行效率獲得控制,程序穩定性獲得提升

圍繞這幾點,拋開常規的增刪改查,咱們來說些不同凡響的

1.不同凡響之一,動態數據源,天生適合分庫分表

可動態配置的功能總比靜態的靈活,擴展性強

目前看到的框架多數訪問對象實例化都相似於

var context = new MsSqlContext(ConnectionString);

在對象初始時,就綁定上了數據庫鏈接串, 這樣寫沒什麼問題,可是很差擴展
如:須要動態切換庫,表,根據租戶信息訪問不一樣的數據庫,或不一樣類型的數據庫,或是讀寫分離,這時,急需處理的技術問題就來了,分庫分表的解決方案,讀寫分離的方案
在數據鏈接綁定的狀況下,這種問題很很差解決
又或者傳入多個鏈接串,在調用時,手動選擇調用的庫或表,對於這種方式,只能說耦合太嚴重,得關心配置,又得關心調用,在CRL以前的版本里,有這樣實現過,棄用了

然而根據IOC的理念,這種問題也不是很差解決,讓數據訪問對象抽象化實現就能辦到了
數據查詢方法再也不直接調用數據訪問對象,而是調用抽象工廠方法,由抽象工廠方法來實例化訪問對象,過程表示爲

數據查詢方法(組件內) => 抽象工廠(組件內) => 抽象實現(組件外)

基於這樣的理念,CRL在設計之初,就使用了的這樣的方式,以代碼爲例

!數據訪問實現

如下實現了分庫分表和mongoDB切換

如下在程序啓動時初始

var builder = new CRL.SettingConfigBuilder();
            builder.UseMongoDB();//引用CRL.Mongo 使用MongoDB
                                 //註冊自定義定位,按MemberSharding傳入數據定義數據源位置
                                 //註冊一
            builder.RegisterLocation<Code.Sharding.MemberSharding>((t, a) =>
            {
                var tableName = t.TableName;
                if (a.Name == "hubro")//當名稱爲hubro,則定位到庫testdb2 表MemberSharding1
                {
                    tableName = "MemberSharding1";
                    return new CRL.Sharding.Location("testdb2", tableName);
                }
                //返回定位庫和表名
                return new CRL.Sharding.Location("testdb", tableName);
            });
            //註冊二
            builder.RegisterDBAccessBuild(dbLocation =>
            {
                if (dbLocation.ManageName == "mongo")
                {
                    var conn = CRL.Core.CustomSetting.GetConfigKey("mongodb");
                    return new CRL.DBAccessBuild(DBType.MongoDB, conn);
                }
                return null;
            });
            //註冊三
            builder.RegisterDBAccessBuild(dbLocation =>
            {
                //自定義定位,由註冊一傳入
                if (dbLocation.ShardingLocation != null)
                {
                    return new CRL.DBAccessBuild(DBType.MSSQL, "Data Source=.;Initial Catalog=" + dbLocation.ShardingLocation.DataBaseName + ";User ID=sa;Password=123");
                }
                return new CRL.DBAccessBuild(DBType.MSSQL, "server=.;database=testDb; uid=sa;pwd=123;");
            });

 

!數據訪問類,相似於倉儲的形式,根據實際業務實現
定位使用示例

public class MemberManage : CRL.Sharding.BaseProvider<MemberSharding>
{
}
var instance=new MemberManage();
instance.Add(new MemberSharding(){Name="hubro"});

根據定位規則 運行到註冊一,此數據將會插入到 庫testdb2 表MemberSharding1

常規切換示例

public class MongoDBTestManage : CRL.BaseProvider<MongoDBModel2>
{
    public override string ManageName => "mongo";
}
var instance=new MongoDBTestManage();
instance.Add(new MongoDBModel2(){name="hubro"});

根據數據訪問規則,運行到註冊二,此數據將會插入mongodb

能夠看到,在上面代碼中,沒有看到任何數據鏈接串的傳入,數據的訪問都由初始時動態分配,對於方法調用是不透明的,調用者不用關心數據源的問題

2.不同凡響之二,表結構自動維護

在新技術的支持下,程序和數據庫的綁定關係愈來愈模糊,如今多是用的SQLSERVER,回頭可能改爲MySql了,或者改爲mongoDB
依賴數據庫開發變成愈來愈不可取,效率也很低
再後來出現了DBFirst方式,雖解決了部份問題,但也很麻煩,如:

創建數據庫模型=>導入數據庫=>T4模版生成代碼(修修補補)

而使用CRL後,過程一步到位,在別人還在用PM設計表結構索引時,你已經設計好了業務結構,效率槓槓的

編寫實體類,實現對象訪問=>調試運行,自動建立表結構(關鍵字,長度,索引)

同時,CRL還提供了手動維護方法,使可以按實體結構重建/檢查數據表
也提供了對象結構文檔導出,不用提心文檔的問題
詳細介紹看這裏
http://www.javashuo.com/article/p-ztrwtyds-s.html

3.不同凡響之三,動態緩存

使用緩存能夠大大提升程序的運行效率,使用REDIS或MONGODB之類的又須要額外維護
對於單應用程序,程序集內緩存很是有用
CRL內置了緩存實現和維護
只需按方法調用就好了,緩存建立維護全自動
如:
從數據庫查

var item = instance.QueryItem(b => b.Id==1)

從緩存查

var item = instance.QueryItemFromCache(b=>b.Id==1);

也支持按查詢自定義緩存

var query = Code.ProductDataManage.Instance.GetLambdaQuery();
//緩存會按條件不一樣緩存不一樣的數據,條件不固定時,慎用
query.Where(b => b.Id < 700);
int exp = 10;//過時分鐘
query.Expire(exp);
var list = query.ToList();

 

基於這樣的形式,能夠將全部查詢都走緩存,不再用擔憂數據庫查詢效率了,簡值中小項目開發利器
詳細介紹看這裏
http://www.javashuo.com/article/p-twhvddck-be.html

4.不同凡響之四,應對複雜查詢

由於沒有查詢分支的概念,處理複雜的查詢,一票ORM估計得退場了,雖然合理的結構設計會減小查詢複雜度,但誰能保證呢
CRL查詢分支過程以下

主查詢 => CreateQuery子查詢 => 返回匿名對象篩選LambdaQueryResultSelect => 主查詢嵌套子查詢 => 返回結果

理論上只要符合調用邏輯,能夠無限嵌套
示例:

var q1 = Code.OrderManage.Instance.GetLambdaQuery();//主查詢
            var q2 = q1.CreateQuery<Code.ProductData>();//建立一個子查詢
            q2.Where(b => b.Id > 0);
            var view = q2.CreateQuery<Code.Member>().GroupBy(b => b.Name).Where(b => b.Id > 0).Select(b => new { b.Name, aa = b.Id.COUNT() });//GROUP查詢
            var view2 = q2.Join(view, (a, b) => a.CategoryName == b.Name).Select((a, b) => new { ss1 = a.UserId, ss2 = b.aa });//關聯GROUP
            q1.Join(view2, (a, b) => a.Id == b.ss1).Select((a, b) => new { a.Id, b.ss1 });//再關聯
            var result = view2.ToList();
            var sql = q1.ToString();

生成SQL打印以下

SELECT t1.[Id] AS Id,
t2.[ss1] AS ss1
FROM [OrderProduct] t1 with(nolock)
INNER JOIN
(SELECT t2.[UserId] AS ss1,
t3.[aa] AS ss2
FROM [ProductData] t2 with(nolock)
INNER JOIN
(SELECT t3.[Name] AS Name,
COUNT(t3.Id) AS aa
FROM [Member] t3 with(nolock)
WHERE (t3.[Id]>@par1)
GROUP BY t3.[Name]) t3 ON (t2.[CategoryName]=t3.[Name])
WHERE (t2.[Id]>@par0) ) t2 ON (t1.[Id]=t2.[ss1])

 

不論是JOIN後再GROUP,仍是GROUP後再GROUP,仍是GROUP後再JOIN,統統不是問題
詳細介紹看這裏
http://www.javashuo.com/article/p-wrchqswn-ms.html

5.不同凡響之五,查詢抽象,非關係型數據庫支持

經過對Lambda表達式的解析,能夠實現不一樣的查詢轉換,如MongoDB,或ElasticSearch(目前只實現了MongoDB)
有人問,這樣有什麼用呢?
好處就是,在CRL框架下,一套LambdaQuery走天下,不用寫各類差別很大的查詢方法了,在動態數據源的支持下,數據拆分遊刃有餘
如:
以前有個報表存在MSSQL裏,發現數據量太大了,查詢慢,改由MongoDB,程序不用怎麼調整,直接在配置裏改成MongoDB便可

以MongoDB爲例

CRLLambdaQuery=>CRLExpression=>BsonDocument=>MongoDB

在[數據訪問實現]示例中,演示瞭如何切換到MongoDB
代碼實現見項目:CRL.Mongo

6.題外之六,請使用倉儲模式

在上文提到,好多框架會直接返回一個數據訪問對象,如

var obj1context.Query<TestEntity>(b=>b.Id==1).ToSingle();

然而這樣會致使濫用,直接在WEB層用,在Service層隨意用,如

var obj2=context.Query<TestEntity2>(b=>b.Id==1).ToSingle();
var obj3=context.Query<TestEntity3>(b=>b.Id==1).ToSingle();

某一天,TestEntity3要換庫了,查找一下引用,傻眼了,上百個引用(接手別人的項目,親身體驗過這種痛苦,一個個改)
好在CRL開始就杜絕了這種狀況發生,對據的訪問必須經過BaseProvider實現,而BaseProvider就是一個倉儲的形式

7.題外之七,查詢效率

ORM效率無非分兩點,實體映射效率和語法解析效率,

對於映射反映在,一次返回多行數據,轉換爲實體集合

對於語法解析效率,按參數調用屢次,返回一行數據,轉換爲實體

測式程序和SQL爲本機,CPU空閒正常,2核6G服務器

一張圖代表一切(不一樣機器實際狀況可能有差別)

CRL效率雖不是最高的,但也不是最差的,測試項目見:

https://github.com/hubro-xx/CRL5/tree/master/Test/CRLTest

 

大概列舉了以上幾項,還有好多特有的東西,輪子好很差,東西南北滾滾試試

CRL開發框架雖然寫好長時間,但一直在DEBUG狀態中, 最近又升級了,分離了數據訪問層,不一樣數據庫引用不一樣的數據訪問層,數據訪問層實現也很簡單,只須要寫兩個文件,如MySql,實現MySqlHelper和MySQLDBAdapter
見:https://github.com/hubro-xx/CRL5/tree/master/CRL.Providers/CRL.MySql
同時,版本也升級到5.1,項目結構發生了改變

源碼地址:https://github.com/hubro-xx/CRL5

CRL目前.NET版本爲.net 4.5, 有時間了再整理整理netstandard版本

除了ORM,CRL還帶 動態API,RPC,WebSocket,api客戶端代理實現https://www.cnblogs.com/hubro/p/11652687.html微服務註冊,發現,調用集成參見:https://github.com/hubro-xx/CRL5/blob/master/Consul/ConsulTest/Program.cs