※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
當全世界的人們隨著網路時代而改變向上時您還停留在『網站美醜不重要』的舊有思維嗎？機會是留給努力改變現況的人們，別再浪費一分一秒可以接觸商機的寶貴時間！
ASP.NET Core 依賴注入最佳實踐與技巧
原文地址：https://medium.com/volosoft/asp-net-core-dependency-injection-best-practices-tips-tricks-c6e9c67f9d96 [正（ke）確(xue)上(shang)網（wang）]
posted by Halil İbrahim Kalkan Jul 12, 2018 · 7 min read
在這篇文章中，我將分享一下在ASP.NET Core應用程序中使用依賴注入的經驗與建議。
主要分享的目的，基於以下幾點原則：
- 有效的設計服務及它們的依賴關係
- 預防多線程問題
- 預防內存移除
- 預防潛在bugs
這篇文章的前提假設你已經對依賴注入和ASP.NET Core由基本的認識，如果還沒有，首先請閱讀ASP.NET Core Dependency Injection documentation。
基礎
構造函數注入
構造函數注入（Constructor injection）用於聲明和獲取服務對服務構造的依賴關係。
public class ProductService
{
private readonly IProductRepository _productRepository;
public ProductService(IProductRepository productRepository)
{
_productRepository = productRepository;
}
public void Delete(int id)
{
_productRepository.Delete(id);
}
}
ProductService在構造函數中注入了它的依賴IProductRepository，然後使用了它的Delete方法。
良好實踐
- 在服務構造函數中顯式定義所需的依賴項。這樣，服務缺失依賴關係就不能構造。
- 將注入的依賴項賦值給一個只讀（read only）字段/屬性（防止在方法調用過程中無意的賦值了其他值）。
屬性注入
ASP.NET Core的標配的依賴注入容器並不支持屬性注入（property injection）。但是你可以使用其他的依賴注入容器支持屬性注入。。
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Logging.Abstractions;
namespace MyApp
{
public class ProductService
{
public ILogger<ProductService> Logger { get; set; }
private readonly IProductRepository _productRepository;
public ProductService(IProductRepository productRepository)
{
_productRepository = productRepository;
Logger = NullLogger<ProductService>.Instance;
}
public void Delete(int id)
{
_productRepository.Delete(id);
Logger.LogInformation(
$"Deleted a product with id = {id}");
}
}
}
ProductService聲明了一個開放了Setter的日誌（Logger）屬性。依賴注入容器能賦值一個可用的值給這個日誌屬性（前提是已經在依賴注入容器內註冊過）。
良好實踐
- 僅對可選依賴項使用屬性注入。這意味着你的服務可以在不提供這些依賴項的情況下正常工作。
- 盡量使用空對象模式(如實例所示)。否則，在使用依賴項時始終做NULL檢查。
服務定位（Service Locator）
服務定位（Service Locator）模式是另一種獲取依賴項的方式。
public class ProductService
{
private readonly IProductRepository _productRepository;
private readonly ILogger<ProductService> _logger;
public ProductService(IServiceProvider serviceProvider)
{
_productRepository = serviceProvider
.GetRequiredService<IProductRepository>();
_logger = serviceProvider
.GetService<ILogger<ProductService>>() ??
NullLogger<ProductService>.Instance;
}
public void Delete(int id)
{
_productRepository.Delete(id);
_logger.LogInformation($"Deleted a product with id = {id}");
}
}
ProductService注入了IServiceProvider，並使用它解析了ProdProductServiService的依賴關係。如果在使用之前注入容器的話，使用GetRequiredService方法會拋異常。另一邊，使用GetService則返回NULL。
當你在構造函數中解析（resolve）依賴服務時，他們隨着服務本身的釋放而釋放，所以你大可不必關係構造函數注入的依賴項的釋放(就像構造函數和屬性注入一樣)。
良好實踐
- 盡可能不要使用服務定位（Service Locator）模式。因為這樣使得服務的依賴關係隱式化（譯註，++服務的依賴關係不是显示的注入，導致代碼層面的服務依賴關係不明確，從構造函數看，只有一個
IServiceProvider的依賴++）。這意味着在創建服務實例時不能显示的看到服務的依賴項。而這對於單元測試尤其重要，因為你可能想要模擬服務的一些依賴項。
- 盡可能使用構造函數解析服務依賴項。在服務方法中解析依賴項會讓應用程序變得更複雜，更容易出錯。接下來，我將介紹這些問題和解決方案。
服務生命周期
在ASP.NET Core依賴注入概念裏面，有三種服務的生命周期:
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
透過資料庫的網站架設建置，建立公司的形象或購物系統，並提供最人性化的使用介面，讓使用者能即時接收到相關的資訊
- Transient服務，在請求或注入服務的時候，每次都創建新實例。
- Scoped服務，在作用域內創建服務。在Web應用程序，每一個web請求都會創建一個新的獨立的服務作用域範圍。這意味着每個web請求通常都創建有作用域的服務
- Singleton服務，每個依賴注入容器會創建一次單例服務。在每個應用程序只會創建一次單例服務，在應用的整個生命周期都可用。
依賴注入容器會跟蹤所有解析出來的服務，在它們的生命周期結束後會釋放掉這些服務。
- 如果服務有依賴項，這些依賴項也會自動釋放。
- 如果服務已經實現了
IDisposable接口，在服務被釋放的時候也會自動調用Dispose方法。
良好實踐
- 盡可能的將你的服務註冊成Transient服務。設計一個Transient服務是相對簡單的，因為你通常不需要關心多線程和內存泄漏的問題，而且這些服務生命周期相對短。
- 小心使用Scoped服務，因為當你創建子作用域或者在非web應用程序使用Scoped服務，會出現一些棘手的問題。
- 小心使用Singleton服務，因為你需要正確處理多線程問題和潛在的內存泄露問題。
- 不要在Singleton服務中依賴一個Transient服務或Scoped服務。因為這時Transient服務會變成Singleton服務，如果Transient服務不支持單例場景，當Singleton服務注入Transient服務時會產生異常問題。ASP.NET Core默認依賴注入容器在這種場景下會拋異常。
在方法內解析服務
在某些場景下，你可能需要在服務的方法中解析另外一個服務。這種情況下請確保在使用服務后及時釋放服務。這才是創建範圍作用域服務的最佳方式。
public class PriceCalculator
{
private readonly IServiceProvider _serviceProvider;
public PriceCalculator(IServiceProvider serviceProvider)
{
_serviceProvider = serviceProvider;
}
public float Calculate(Product product, int count,
Type taxStrategyServiceType)
{
using (var scope = _serviceProvider.CreateScope())
{
var taxStrategy = (ITaxStrategy)scope.ServiceProvider
.GetRequiredService(taxStrategyServiceType);
var price = product.Price * count;
return price + taxStrategy.CalculateTax(price);
}
}
}
PriceCalculator在構造函數里注入了IServiceProvider並賦值給以只讀字段。然後PriceCalculator在Calculate的方法內創建了一個子範圍作用域。使用scope.ServiceProvider來解析服務依賴，而不是用_serviceProvider實例。這樣，在子範圍作用域內被解析的所有服務會在using的聲明結束后自動釋放。
良好實踐
- 如果在方法內解析服務，請始終創建子範圍作用域，以確保已解析的服務被正確釋放。
- 如果一個方法使用IServiceProvider作為參數，那麼可以直接使用它解析服務依賴，而不需要關心依賴服務是否釋放。創建/管理服務範圍作用域是調用方法代碼的職責。遵循這一原則可以使代碼更簡潔。
- 不要保存對已解析服務的引用!否則，在使用對象引用時訪問已釋放的服務可能會導致內存泄漏(除非已解析的服務是單例的)。
單例服務 Singleton Services
單例服務通常為了保持應用程序狀態而設計。緩存是一個應用程序狀態的最好示例。
public class FileService
{
private readonly ConcurrentDictionary<string, byte[]> _cache;
public FileService()
{
_cache = new ConcurrentDictionary<string, byte[]>();
}
public byte[] GetFileContent(string filePath)
{
return _cache.GetOrAdd(filePath, _ =>
{
return File.ReadAllBytes(filePath);
});
}
}
FileService只是簡單的緩存了文件內容來減少磁盤讀取。像這樣的服務應該設計成單例服務。否則緩存將不能正常工作。
良好實踐
- 如果一個服務持有某種狀態，應該以線程安全的方式訪問這個狀態。因為所有的請求將併發的訪問同一個實例，使用
ConcurrentDictionary而不是Dictionary來確保線程安全。
- 不要在單例服務內使用Scoped/Transient服務，因為Transient服務可能不是線程安全的設計。如果確實需要使用，請注意多線程（例如使用Lock）。
- 引起內存泄漏的通常是由單例服務引起的。在應用程序結束之前，單例服務不會被釋放。它們實例化類(或注入實例)也不會提前被釋放，它們也會一直留在內存中，直到應用程序結束。確保在適當的時候釋放服務，請參閱在方法內解析服務。
- 如果使用緩存數據（例如上述代碼示例中文件內容的緩存），應該創建一種機制當原始數據發生變更的時候去更新或淘汰已緩存的數據（示例中當磁盤的文件變更時應該更新緩存）。
範圍作用域服務Scoped Services
範圍作用域服務似乎是一個為每個web請求存儲數據的候選方式。因為ASP.NET Core為每一個Web請求都會創建一個服務範圍作用域。因此一個服務註冊成Scoped服務，在Web請求過程可以共享這個服務。
public class RequestItemsService
{
private readonly Dictionary<string, object> _items;
public RequestItemsService()
{
_items = new Dictionary<string, object>();
}
public void Set(string name, object value)
{
_items[name] = value;
}
public object Get(string name)
{
return _items[name];
}
}
如果RequestItemsService註冊成範圍作用域的服務，並將RequestItemsService注入到兩個不同的服務中，這兩個服務可以訪問到另外一個服務添加的數據，因為這兩個服務在一個Web請求中是共享RequestItemsService實例的。
但是，現實情況可能不完全是這樣的。如果你創建了子範圍作用域並在子作用域範圍內解析RequestItemsService，你會得到一個全新的RequestItemsService，而這並非我們所期望的那樣。所有Scoped服務並非一個Web請求時共享一個服務實例。
你可能會認為你不會犯這樣明顯的錯誤（在子作用域內解析服務依賴）。但是這不是錯誤（一個常規用法而已）並且情況並沒有那麼簡單。假設在你的服務中有龐大的服務依賴關係，你可能不知道是否有人會這麼做（在子作用域內解析服務依賴）。
良好實踐
- Scoped服務可以視作一種優化手段（在一個web請求中不想注入太多服務）。這樣在同一個Web請求中所有的服務使用同一個實例。
- Scoped服務不需要設計線程安全。因為Scoped服務通常在一個線程或Web請求中使用，但是，這種場景下，不應該在不同線程之間共享Scoped服務。
- 如果要設計一個作用域服務來在web請求中的其他服務之間共享數據，小心上述問題。你可以使用
HttpContext（通過IHttpContextAccessor來訪問它）來存儲每一個Web請求需要存儲的數據，這是安全的處理方式。HttpContext生命周期並不是Scoped。實際上並沒有注入到依賴注入的容器內（這是為什麼使用IHttpContextAccessor訪問它而不是注入到容器內的原因）。++在一個Web請求中，HttpContextAccessor使用AsyncLocal來共享相同的HttpContext++。
結論
依賴注入在最初使用的時候好像是挺簡單的。如果不遵循嚴格的使用原則，依然會有潛在的多線程和內存泄漏問題。我在開發ASP.NET Boilerplate框架過程中，基於我的實踐體會分享了這些實踐原則。
總結
在使用ASP.NET Core 依賴注入時需要注意幾項：
- 在構造函數中显示的注入依賴關係。
- 在依賴關係眾多時，職責單一原則，考慮拆分職責
- 更有利於單元測試。
- 屬性注入，適用於可選依賴項，不影響服務正常運行，考慮空實現模式。
- 通常我們在設計框架/基類時，可以適當引入屬性注入，這樣可以使得繼承類代碼更簡潔。
- 必要時，屬性提供懶加載方式，提高服務啟動速度。
- 選擇合適的服務生命周期。順序依次Transient > Singleton > Scoped，不確定時使用Transient ，明確使用場景的時候考慮Singleton和Scoped。同需要需要考慮服務的構建成本。
- Transient服務的生命周期短，可以有效的規避多線程和內存泄漏問題，同時也引起應用程序的內存使用量上升，帶了部分性能問題。
- 在Singleton服務中，禁止依賴Transient/Scoped服務，一方面，Transient/Scoped服務也會變成單例服務。另一方面，Transient/Scoped服務沒有考慮多線程問題。
- 在使用Singleton服務時，多注意潛在的線程安全和內存泄漏問題。
- 在非Web應用場景和子作用服務場景，Scoped服務，並不能正確處理一個線程內共享實例。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
※想知道最厲害的網頁設計公司嚨底家"!
RWD（響應式網頁設計）是透過瀏覽器的解析度來判斷要給使用者看到的樣貌
