跳到主要內容

[ASP.NET Core 3框架揭秘] 依賴注入[10]：與第三方依賴注入框架的適配

.NET Core具有一個承載（Hosting）系統，承載需要在後台長時間運行的服務，一個ASP.NET Core應用僅僅是該系統承載的一種服務而已。承載系統總是採用依賴注入的方式來消費它在服務承載過程所需的服務。對於承載系統來說，原始的服務註冊總是體現為一個IServiceCollection集合，最終的依賴注入容器則體現為一個IServiceProvider對象，如果要將第三方依賴注入框架整合進來，就需要利用它們解決從IServiceCollection集合到IServiceProvider對象之間的適配問題。


一、IServiceCollection =>ContainerBuilder=>IServiceProvider


具體來說，我們可以在IServiceCollection集合和IServiceProvider對象之間設置一個針對某個第三方依賴注入框架的ContainerBuilder對象。我們先利用包含原始服務註冊的IServiceCollection集合來創建一個ContainerBuilder對象，再利用該對象來構建作為依賴注入容器的IServiceProvider對象。



二、 IServiceProviderFactory<TContainerBuilder>


如上圖所示的兩種轉換是利用一個IServiceProviderFactory<TContainerBuilder>對象完成的。如下面的代碼片段所示，IServiceProviderFactory<TContainerBuilder>接口定義了兩個方法，其中CreateBuilder方法利用指定的IServiceCollection集合創建出對應的ContainerBuilder對象，而CreateServiceProvider方法則進一步利用這個ContainerBuilder對象創建出作為依賴注入容器的IServiceProvider對象。


public interface IServiceProviderFactory<TContainerBuilder> 
 { 
     TContainerBuilder CreateBuilder(IServiceCollection services); 
     IServiceProvider CreateServiceProvider(TContainerBuilder containerBuilder); 
 }

.NET Core的承載系統總是利用註冊的IServiceProviderFactory<TContainerBuilder>服務來創建最終作為依賴注入容器的IServiceProvider對象。承載系統默認註冊的是如下這個DefaultServiceProviderFactory類型。如下面的代碼片段所示，DefaultServiceProviderFactory對象會直接調用指定IServiceCollection集合的BuildServiceProvider方法創建出對應的IServiceProvider對象。


public class DefaultServiceProviderFactory :  IServiceProviderFactory<IServiceCollection> 
 {    
     public DefaultServiceProviderFactory()  : this(ServiceProviderOptions.Default){} 
     public DefaultServiceProviderFactory(ServiceProviderOptions options) =>_options = options; 
  
     public IServiceCollection CreateBuilder(IServiceCollection services)  => services; 
  
     public IServiceProvider CreateServiceProvider( IServiceCollection containerBuilder) =>  containerBuilder.BuildServiceProvider(_options); 
 }

三、整合第三方依賴注入框架


為了讓讀者朋友對利用註冊的IServiceProviderFactory<TContainerBuilder>服務整合第三方依賴注入框架具有更加深刻的理解，我們來演示一個具體的實例。我們在《》創建了一個名為Cat的"迷你版"依賴注入框架，接下來我們將提供一個具體IServiceProviderFactory<TContainerBuilder>實現類型完成對它的整合。


我們首先創建一個名為CatBuilder的類型作為對應的ContainerBuilder。由於需要涉及針對服務範圍的創建，我們在CatBuilder類中定了如下兩個內嵌的私有類型，其中表示服務範圍的ServiceScope對象實際上就是對一個IServiceProvider對象的封裝，另一個ServiceScopeFactory類型表示創建該對象的工廠，它是對一個Cat對象的封裝。


public class CatBuilder 
 {     
     private class ServiceScope : IServiceScope 
     { 
         public ServiceScope(IServiceProvider serviceProvider) => ServiceProvider = serviceProvider; 
         public IServiceProvider ServiceProvider { get; } 
         public void Dispose()=> (ServiceProvider as IDisposable)?.Dispose(); 
 } 
  
     private class ServiceScopeFactory : IServiceScopeFactory 
     { 
         private readonly Cat _cat; 
         public ServiceScopeFactory(Cat cat) => _cat = cat; 
         public IServiceScope CreateScope() => new ServiceScope(_cat); 
     } 
 }

一個CatBuilder對象是對一個Cat對象的封裝，它的BuildServiceProvider方法會直接返回這個Cat對象，並作為最終提供的依賴注入容器。CatBuilder在初始化過程中添加了針對IServiceScopeFactory接口的服務註冊，具體註冊的是根據作為當前子容器的Cat對象創建的ServiceScopeFactory對象。為了實現程序集範圍內的批量服務註冊，我們為CatBuilder定義了一個Register方法。


public class CatBuilder 
 { 
     private readonly Cat _cat; 
     public CatBuilder(Cat cat) 
     { 
         _cat = cat; 
         _cat.Register<IServiceScopeFactory>( c => new ServiceScopeFactory(c.CreateChild()), Lifetime.Transient); 
     } 
     public IServiceProvider BuildServiceProvider() => _cat; 
     public CatBuilder Register(Assembly assembly) 
     { 
         _cat.Register(assembly); 
         return this; 
     } 
     ... 
 }

如下所示的CatServiceProviderFactory類型實現了IServiceProviderFactory<CatBuilder>接口。在實現的CreateBuilder方法中，我們創建了一個Cat對象，並將指定IServiceCollection集合包含中的服務註冊（ServiceDescriptor對象）轉換成兼容Cat的服務註冊（ServiceRegistry對象）並應用到創建的Cat對象上。我們最終利用這個Cat對象創建出返回的CatBuilder對象。實現的另一個方法CreateServiceProvider返回的是調用CatBuilder對象的CreateServiceProvider方法得到的IServiceProvider對象。


public class CatServiceProviderFactory : IServiceProviderFactory<CatBuilder> 
 { 
     public CatBuilder CreateBuilder(IServiceCollection services) 
     { 
         var cat = new Cat(); 
         foreach (var service in services) 
         { 
             if (service.ImplementationFactory != null) 
             { 
                 cat.Register(service.ServiceType, provider ) => service.ImplementationFactory(provider),   service.Lifetime.AsCatLifetime()); 
             } 
             else if (service.ImplementationInstance != null) 
             { 
                 cat.Register(service.ServiceType, service.ImplementationInstance); 
             } 
             else 
             { 
                 cat.Register(service.ServiceType, service.ImplementationType,    service.Lifetime.AsCatLifetime()); 
             } 
         } 
         return new CatBuilder(cat); 
     } 
     public IServiceProvider CreateServiceProvider(CatBuilder containerBuilder) => containerBuilder.BuildServiceProvider(); 
 }

Cat具有.NET Core依賴注入框架一致的服務生命周期表達方式，所以我們在將服務註冊從ServiceDescriptor類型轉化成ServiceRegistry類型時，可以實現直接完成兩種生命周期模式的轉換，具體的轉換實現在如下這個AsCatLifetime擴展方法中。


internal static class Extensions 
 { 
     public static Lifetime AsCatLifetime(this ServiceLifetime lifetime) 
     { 
         return lifetime switch 
         { 
             ServiceLifetime.Scoped => Lifetime.Self, 
             ServiceLifetime.Singleton => Lifetime.Root, 
             _ => Lifetime.Transient, 
         }; 
     } 
 }

接下來我們演示如何利用CatServiceProviderFactory來創建作為依賴注入容器的IServiceProvider對象。我們定義了如下的接口和對應的實現類型，其中Foo、Bar、Baz和Qux類型分別實現了對應的接口IFoo、IBar、IBaz和IQux，其中Qux類型上標註了一個MapToAttribute特性註冊了與對應接口IQux之間的映射。為了反映Cat對服務實例生命周期的控制，我們讓它們派生於同一個基類Base。Base實現了IDisposable接口，我們在其構造函數和實現的Dispose方法中輸出相應的文本以確定對應的實例何時被創建和釋放。


public interface IFoo {} 
 public interface IBar {} 
 public interface IBaz {}  
 public interface IQux {} 
 public interface IFoobar<T1, T2> {} 
 public class Base : IDisposable 
 { 
     public Base()  => Console.WriteLine($"Instance of {GetType().Name} is created."); 
     public void Dispose()  => Console.WriteLine($"Instance of {GetType().Name} is disposed."); 
 } 
  
 public class Foo : Base, IFoo{ } 
 public class Bar : Base, IBar{ } 
 public class Baz : Base, IBaz{ }  
 [MapTo(typeof(IQux), Lifetime.Root)] 
 public class Qux : Base, IQux { } 
 public class Foobar<T1, T2>: IFoobar<T1,T2> 
 { 
     public IFoo Foo { get; } 
     public IBar Bar { get; } 
     public Foobar(IFoo foo, IBar bar) 
     { 
         Foo = foo; 
         Bar = bar; 
     } 
 }

在如下所示的演示程序中，我們創建了一個ServiceCollection集合，並採用三種不同的生命周期模式分別添加了針對IFoo、IBar和IBaz接口的服務註冊。我們接下來根據這個ServiceCollection集合創建了一個CatServiceProviderFactory對象，並調用其CreateBuilder方法創建出對應的CatBuilder對象。我們隨後調用了CatBuilder對象的Register方法完成了針對當前入口程序集的批量服務註冊，其目的在於添加針對IQux/Qux的服務註冊。


class Program 
 { 
     static void Main() 
     { 
         var services = new ServiceCollection() 
             .AddTransient<IFoo, Foo>() 
             .AddScoped<IBar>(_ => new Bar()) 
             .AddSingleton<IBaz>(new Baz()); 
  
         var factory = new CatServiceProviderFactory(); 
         var builder = factory.CreateBuilder(services) 
             .Register(Assembly.GetEntryAssembly()); 
         var container = factory.CreateServiceProvider(builder); 
  
         GetServices(); 
         GetServices(); 
         Console.WriteLine("\nRoot container is disposed."); 
         (container as IDisposable)?.Dispose(); 
  
         void GetServices() 
         { 
             using (var scope = container.CreateScope()) 
             { 
                 Console.WriteLine("\nService scope is created."); 
                 var child = scope.ServiceProvider; 
  
                 child.GetService<IFoo>(); 
                 child.GetService<IBar>(); 
                 child.GetService<IBaz>(); 
                 child.GetService<IQux>(); 
  
                 child.GetService<IFoo>(); 
                 child.GetService<IBar>(); 
                 child.GetService<IBaz>(); 
                 child.GetService<IQux>();                      
                 Console.WriteLine("\nService scope is disposed."); 
             } 
         } 
     } 
 }

在調用CatServiceProviderFactory對象的CreateServiceProvider方法創建出作為依賴注入容器的IServiceProvider對象之後，我們先後兩次調用了本地方法GetServices方法。GetServices方法會利用這個IServiceProvider對象創建一個服務範圍，並利用此服務範圍內的IServiceProvider提供兩組服務實例。通過CatServiceProviderFactory創建的IServiceProvider對象在最終通過調用其Dispose方法進行釋放。該程序運行之後會在控制台上輸出如圖4-16所示的結果，輸出結果體現的服務生命周期與演示程序體現的是完全一致的。












本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?



※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!



※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光



※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師"嚨底家"!!


Orignal From: [ASP.NET Core 3框架揭秘] 依賴注入[10]：與第三方依賴注入框架的適配

留言

張貼留言

這個網誌中的熱門文章

有了四步解題法模板，再也不害怕動態規劃！（看不懂算我輸）

導言 動態規劃問題一直是算法面試當中的重點和難點，並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到，這篇文章的目的主要是解釋清楚 什麼是動態規劃 ，還有就是面對一道動態規劃問題，一般的 思考步驟 以及其中的注意事項等等，最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃，或者僅僅只有耳聞，或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 "，如果更準確些，其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中，大家經常會遇到一些系統配置的問題，配置不對，系統就會報錯，這個時候一般都會去 Google 或者是查閱相關的文檔，花了一定的時間將配置修改好。 過了一段時間，去到另一個系統，遇到類似的問題，這個時候已經記不清之前修改過的配置文件長什麼樣，這個時候有兩種方案，一種方案還是去 Google 或者查閱文檔，另一種方案是借鑒之前修改過的配置，第一種做法其實是萬金油，因為你遇到的任何問題其實都可以去 Google，去查閱相關文件找答案，但是這會花費一定的時間，相比之下，第二種方案肯定會更加地節約時間，但是這個方案是有條件的，條件如下： 之前的問題和當前的問題有着關聯性，換句話說，之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中，可以看到的是，上面這兩個條件均滿足，大可去到之前配置過的文件中，將配置拷貝過來，然後做些細微的調整即可解決當前問題，節約了大量的時間。 不知道你是否從這些描述中發現，對於一個動態規劃問題，我們只需要從兩個方面考慮，那就是 找出問題之間的聯繫 ，以及 記錄答案 ，這裏的難點其實是找出問題之間的聯繫，記錄答案只是順帶的事情，利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話，接    動態規劃 算法是通過拆分問題，定義問題狀態和狀態之間的關係，使得問題能夠以遞推（或者說分治）的方式去解決。它的幾個重要概念如下所述。    階段： 對於一個完整的問題過程，適當的切分為若干個相互聯繫的子問題，每次在求解一個子問題...
張貼留言
閱讀完整內容

計算機本地文件快要滅絕了

　　 編者按： 文件是数字世界的基石，是我們基本的工作單位。但是，隨着互聯網的雲化、平台化、服務化，文件日益變得可有可無。這樣一種改變究竟好不好呢？喜歡懷舊的 Simon Pitt 開始回顧各種文件的好處，哪怕這讓他顯得不合時宜。原文發表在 medium 上，標題是：Computer Files Are Going Extinct 　　我喜歡文件。我喜歡對文件重命名、移動、排序，改變它們在文件夾中的显示方式，去備份文件，將之上傳到互聯網，恢復它們，對其進行複製，甚至還可以對文件進行碎片整理。作為信息存儲方式的一種隱喻，在我看來文件是很出色的。我喜歡把文件當作一個工作單位。如果我要寫篇文章，文章會放在文件裏面。如果我要生成圖像，圖像會保存進文件裏面。 　　 謳歌 files.doc 　　文件是擬物化的。這是個很花哨的詞，只是用來表示文件是反映現實物品的一個数字概念。比方說，Word 文檔就像一張紙，躺在你的辦公桌上（desktop）。JPEG 就像一幅畫，等等。它們每個都有一個小圖標，圖標的樣子看起來像它們所代表的現實物品。一堆紙，一個畫框，一個馬尼拉文件夾。真的挺很迷人的。 　　我喜歡文件的一點是，不管裏面有什麼，跟文件的交互方式總是一致的。我上面提到的那些東西——複製、排序、碎片整理——我可以對任何文件進行那些處理。文件可能是圖像、遊戲的一部分、也可能是我最喜歡的餐具清單。碎片整理程序不在乎它是什麼。它不會去判斷內容。 　　自從我開始在 Windows 95 裏面創建文件以來，我就一直都很喜歡文件。但是我注意到我們已經開始慢慢地遠離把文件當作基本工作單位的做法。 Windows95。我的計算機 　　 services.mp3 的興起 　　十幾歲的時候，我開始痴迷於收集和管理数字音樂：我收藏 MP3 文件。一大堆的 128 kbps MP3 文件。如果你足夠幸運，有自己的 CD 刻錄機的話，就可以將它們刻錄到 CD 上，然後在朋友之間傳遞。一張 CD 可以容納 700 MB。這相當於將近 500 張軟盤！ 　　我會仔細端詳我的收藏，然後煞費苦心地給它們添加上 IDv1 和 IDv2 音樂標籤。隨着時間的流逝，大家開始開發可以在雲端自動獲取曲目列表的工具，這樣你就可以檢查和驗證 MP3 的質量。有時候我甚至會去聽那些該死的東西，儘管...
張貼留言
閱讀完整內容

純電動 Mini Cooper SE 將成為中國國產車，年產 16 萬輛

BMW 集團與中國長城汽車合資，將於江蘇建立新廠，專門投入生產 MINI Cooper SE 和部分長城品牌電動車，預計於 2022 年完工並投入生產，每年將可生產 16 萬輛電動車。 靈動可愛的 Mini Cooper，在許多車迷心中都有著特殊的地位，今年 7 月發表了首款純電動版本的 Mini Cooper SE 之後，獲得熱烈迴響，預訂數量已接近 8 萬台，顯示大家對於純電 Mini 的熱愛，因為油電版的 Mini Cooper Countryman 的全球總銷售量也才 3 萬出頭。 Mini Cooper SE 之前公布了官方定價，最低從 27,900 歐元起算，美國售價約 29,900 美元。相比現有的三門款，只貴了一成左右。然而，三年後，中國消費者將有機會買到最便宜的電動 Mini。 電動 Mini Cooper SE 最低價是 27,900 歐元，扣掉全額補助最低可以到 24,400 歐元。 BMW 集團與中國長城汽車集團於 2018 年宣布，將組建合資公司光束汽車，投入在中國的電動車生產計畫，而現在他們正式宣布啟動計畫，於江蘇張家港打造一個新工廠，全部投入電動車的製造，包括了 Mini Cooper SE 和其他長城汽車旗下的電動車。 目前的電動 Mini 只在英國牛津工廠製造，不難想像當產能轉移到中國後，Mini Cooper SE 的價格將有機會進一步調降，來競爭全球最大的電動車市場。這座屬於合資公司光束汽車的新工廠，採用一個新的產銷模式，由 BMW 和長城共同合作開發、設計、製造新產品，但是銷售通路完全沿用原本的品牌渠道。 換句話說，2020 年到 2022 年銷售的電動 Mini，將會是英國製造，而 2022 年後就會有中國製造版本開賣，考量到 Mini 在中國每年約有 30 萬輛的銷售額，同時油電版的 Coutryman 銷量更佔了全球將近五分之一，無怪乎 BMW 會想在最接近主要市場的地方蓋工廠囉。 外型完美復刻油車版 最後，簡單介紹一下 Mini Cooper SE 這台車。Mini 在電動化的路上，盡力保持著跟經典造型一致的設計，畢竟大家愛的就是它的設計。電動版的 Mini 車頭、車身跟車屁股都多了一個黃色的插頭標誌，車頭的氣壩則變成封閉式設計，除此之外，幾乎看不出來差別，連馬達...
張貼留言
閱讀完整內容