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還提供了手動維護方法,使能夠按物體結構重建/檢查資料表
也提供了物件結構檔案匯出,不用提心檔案的問題
詳細介紹看這里
https://www.cnblogs.com/hubro/p/6038118.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();
基于這樣的形式,可以將所有查詢都走快取,再也不用擔心資料庫查詢效率了,簡值中小專案開發利器
詳細介紹看這里
https://www.cnblogs.com/hubro/p/6038540.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 ss1FROM [OrderProduct] t1 with(nolock)INNER JOIN(SELECT t2.[UserId] AS ss1,t3.[aa] AS ss2FROM [ProductData] t2 with(nolock)INNER JOIN(SELECT t3.[Name] AS Name,COUNT(t3.Id) AS aaFROM [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,通通不是問題
詳細介紹看這里
https://www.cnblogs.com/hubro/p/6096544.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/TestConsole
大概列舉了以上幾項,還有好多特有的東西,輪子好不好,東西南北滾滾試試
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
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/26014.html
標籤：架構設計
上一篇：架構師主要做些什么，你知道嗎？
下一篇：分布式系統環境搭建