您好,登錄后才能下訂單哦!
ABP vNext的基礎知識是什么,相信很多沒有經(jīng)驗的人對此束手無策,為此本文總結(jié)了問題出現(xiàn)的原因和解決方法,通過這篇文章希望你能解決這個問題。
ABP vNext(以下簡稱ABP)的前身是asp.net boilerplate(老版abp),它不是一個簡單的版本更新,而是完全基于.NET Core的重寫。
ABP是基于DDD:Domain-Driven Design(領域驅(qū)動設計)去開發(fā)的,當然框架本身不強制你使用DDD,但是他建議把DDD作為最佳實踐。如果了解DDD,并且使用過老版本abp的話,看官方文檔可能就比較輕松,反之則會比較吃力。。。首先DDD理論就非常抽象和復雜,要深刻理解它并不容易;其次是ABP內(nèi)部使用了很多開源組件,比如EF Core,IdentityServer4,Autofac,AutoMapper,Swagger等等,所以也需要對這些組件有所了解。
下面簡單介紹一下ABP官方文檔上一些重要的關鍵字,先理解這些關鍵字,才能更好的進一步學習。
審計是用于追蹤數(shù)據(jù)變化的過程。平時開發(fā)中,你一定經(jīng)常見到類似創(chuàng)建時間、創(chuàng)建人、修改時間、修改人等屬性,這些屬性就是用于數(shù)據(jù)審計。ABP框架提供了一些接口和基類來標準化這些屬性,并自動設置它們的值;并且ABP提供了一個可擴展的審計日志系統(tǒng),自動化的根據(jù)約定記錄審計日志,并提供配置來控制審計日志的級別。ABP中審計相關基類/接口有:IAuditedObject
、AuditedEntity
、AuditedAggregateRoot
等等。
使應用程序支持多國語言。ABP的本地化系統(tǒng)與ASP.NET Core的本地化兼容。
事件總線是對觀察者(發(fā)布-訂閱)模式的一種實現(xiàn)。它是一種集中式事件處理機制,允許不同的組件之間進行彼此通信而又不需要相互依賴,達到一種解耦的目的。
如果沒有接觸過Event Bus,可能不太好理解。一個不太恰當?shù)睦樱篈需要租房,B需要把房子租出去,A想直接找到B是比較困難的,A也不想去認識B,所以才有房產(chǎn)中介C,C就是Event Bus;B提前跟C說我的房子需要出租,A跟C說我給你錢你幫我租一個房,那么C很容易就幫A找到B完成租房,A甚至不需要知道B是誰,這里A就是事件的發(fā)布者,B是事件的訂閱者。ABP支持本地Event Bus和分布式Event Bus。
多租戶是一種軟件架構技術,這種架構可以讓多個租戶共用相同的系統(tǒng),并且可以確保各租戶間數(shù)據(jù)的隔離性。相信很多人都遇到過類似需求,同一個系統(tǒng)中根據(jù)不同客戶區(qū)分數(shù)據(jù);通常我們會在數(shù)據(jù)庫表中增加一個客戶Id作為標識,或者根據(jù)不同客戶讀取不同的數(shù)據(jù)庫,這都是多租戶數(shù)據(jù)隔離的實現(xiàn)方式,想自己很好的實現(xiàn)多租戶還是很繁瑣的。ABP的多租戶模塊提供了創(chuàng)建多租戶應用程序的基本功能,可以很輕松的幫你實現(xiàn)多租戶。
一個沒有從其屬性,而是通過連續(xù)性和身份的線索來定義的對象。
官方文檔中這句話非常難理解。。。
簡單來說,當一個對象只能由他的標識(Id)來區(qū)分,而不是從其他屬性來區(qū)分時,這種對象被稱為實體。比如有很多叫“張三”的男人,你不能通過姓名和性別來區(qū)分到底是哪個張三,只能通過Id。實體是可以持續(xù)變化的,我們可以對實體進行多次修改,但是無論怎么修改,實體始終擁有它唯一的標識。DDD中的實體通常都是充血模型,充血模型就是實體中不光有屬性,還會包含行為(方法),反之DTO,ViewModel就是典型的貧血模型。實體通常映射到關系型數(shù)據(jù)庫的表中,ABP中實體相關的基類/接口有:Entity
、IEntity
、AuditedEntity
等等。
值對象和實體恰好相反,它不需要唯一標識,并且它不可以被改變。值對象通常是用來度量和描述事物,當你只關注某個對象的屬性時,該對象便可以是一個值對象。比如“北京”就是“北京”,不存在Id=1或者Id=2的北京的說法。當然,值對象雖然不存在唯一標識,但是不代表它在數(shù)據(jù)庫中就沒有Id主鍵。。。
聚合是業(yè)務邏輯緊密關聯(lián)的實體和值對象組合而成,聚合是數(shù)據(jù)修改和持久化的基本單元,聚合后產(chǎn)生的根實體稱為聚合根。若一個聚合僅有一個實體,那這個實體就是聚合根。聚合根被視為一個單元,你不能單獨去修改聚合根中的子實體。例如,某個業(yè)務流程中,會操作A、B、C、D四個對象(簡單理解為數(shù)據(jù)庫表),那么將ABCD聚合,產(chǎn)生一個聚合根E,對外部來說只需要操作E就可以了,領域內(nèi)部會處理好ABCD。這樣一方面避免了多個對象的混亂,另一方面也保證了數(shù)據(jù)的完整性,不會出現(xiàn)AB操作成功了,CD操作失敗了,導致數(shù)據(jù)庫產(chǎn)生臟數(shù)據(jù)。
聚合根引用聚合根:通過ID。
聚合根引用實體:通過對象(導航屬性)。
聚合根引用值對象:通過對象(導航屬性)。
倉儲用于操作領域?qū)ο螅▽嶋H就是操作數(shù)據(jù)庫),通常會為每個聚合根或不同的實體創(chuàng)建對應的倉儲。ABP也提供了通用的泛型倉儲:IRepository<TEntity, TKey>
,內(nèi)置了增刪改查基本功能,直接注入就可以使用。
應用層處于展示層與領域?qū)又g,展示層通常調(diào)用應用服務,應用服務調(diào)用領域然后返回數(shù)據(jù)給展示層。展示層也可以直接調(diào)用領域。APB中應用服務相關的基類/接口有:IApplicationService
、ApplicationService
、ICrudAppService
、CrudAppService
等等。
通常領域?qū)ο蟛贿m合直接在應用層與展示層之間傳遞,比如User中的Passwod字段,這時候就需要用到DTO,DTO和ViewModel類似。ABP提供了一些DTO基類/接口:IEntityDto
、EntityDto
、AuditedEntityDto
等等。
UOW模式是為了保證一次業(yè)務操作的數(shù)據(jù)完整性。ABP框架的UOW實現(xiàn)提供了對應用程序中的數(shù)據(jù)庫連接和事務范圍的抽象和控制,使用ABP的話通常你不用自己去寫數(shù)據(jù)庫事務相關代碼。實際上工作單元不一定非要創(chuàng)建數(shù)據(jù)庫事務,比如HTTP GET請求就不會啟動事務性UOW,它們?nèi)匀粏覷OW,但不創(chuàng)建數(shù)據(jù)庫事務。這一切都由ABP框架自動完成。
看完上述內(nèi)容,你們掌握ABP vNext的基礎知識是什么的方法了嗎?如果還想學到更多技能或想了解更多相關內(nèi)容,歡迎關注億速云行業(yè)資訊頻道,感謝各位的閱讀!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。