C# 類中的只讀引用變量

Question

我有一個實例類，它實現了一個接口，並且除了接口方法之外的所有方法都是靜態的。 所有的類變量也是靜態的。 其中兩個靜態變量實際上是實例變量並標記為只讀。 這些只讀實例變量是內聯初始化的。

這是一個例子

public class Test : ITestInterface
{

  public static readonly DbConnection Connection = new DbConnection();

  public void static TestMethod1(){
  }

  public List<string> static TestMethod2(){
  }

}

我的框架層中有很多使用靜態連接變量的方法。

這是一個有效的設計嗎？ 我想為所有 API 調用使用相同的對象。 這個想法是為了避免創建多個連接對象。 在任何一天，有來自客戶端的調用負載，都有可能創建 10,000 個連接對象。 我試圖避免這種情況。

Answer 1

這個想法是為了避免創建多個連接對象

用於處理這種情況的模式是單例模式。 也不是您必須以這種方式實施。 但這是一般准則。

在您的具體示例中，您可以做的是渲染類private構造函數。

public class Test : ITestInterface
{
  ...
  private Test() {}
  ..
}

這將使創建類的實例成為不可能，因此也無法從它派生。 因此，您的Test類的使用者將別無選擇，只能訪問它的static成員。

但總的來說，我強烈建議您查看上面鏈接的模式。 它可能會照耀你在做什么，有一些啟發，要如何做到這一點。

Answer 2

很少有事情，首先您基本上將連接用作單例。 這可以是一個完美的設計模式，但有很多考慮因素，讓我擔心你像你發布的那樣使用它。

1. 你有多個線程訪問這個嗎？ 連接線程安全嗎？ 所有的變量都是線程安全的嗎？ 如果不是，您正在尋找麻煩。

2. 您真的想在應用程序的整個生命周期中保持一個連接打開嗎？ 如果連接關閉會發生什么？ 單身人士通常是處理這類問題的經理，而不是單一資源。

3. 您知道多個連接會低效嗎？ 大多數連接層（如 SQL）管理一個連接池，可以非常有效地管理連接，並且無需您擔心。 這通常是一種更好的模式，除非您可以使用性能計數器證明您可以更有效地自己管理連接

我會謹慎地使用單例，並且僅在資源真正全局且不變以及線程安全的情況下。 如果它是全局的，但需要圍繞它進行管理和線程安全（想想連接），那么你最好添加一個自定義管理器類。 但同樣，只有在您能證明您可以手動處理比使用普通連接池更多的連接和吞吐量時才這樣做。