.NET項目升級手記：可爲空引用

c# 8引入了新特性：「可爲空引用」（詳情），這個功能我的以爲挺好的，可以很是明確的表現程序設計者的意圖，編譯器可以進行檢查，盡最大可能減少NullReferenceException錯誤。

若是是新項目，那麼上手很簡單，一點點搭建起來，遇山開山，遇河渡河。可是對於我這種手頭上的項目大多都是之前建立的狀況，就要稍微作那邊麼一點操做了。

要看完整說明，請查看開頭的那個連接。

準備

首先評估一下幾個條件：

1. 項目能夠基於.NET CORE 3.0及以上編譯。若是不行，那麼就請直接右上角點×。
2. 是否是大多數的變量都須要null引用？若是是的話，我的以爲不值得費勁了。

操做

以一個ASP.NET WEBAPI爲例，項目修改前是可以正常編譯無錯誤無警告的。

1. 啓用Nullable（可爲空引用類型）

Nullable默認是不啓用的，須要作一些修改以啓用。有兩種方式：

• 修改csproj文件，在ProperyGroup裏面添加 enable 項。

對於比較小型的項目，能夠直接修改，這樣彈出來的警告或者錯誤會比較少，方便咱們快速改正。

• 使用編譯器指令#nullable enable和#nullable restore進行修改。在代碼段的開頭enable，結尾處restore。

對於中大型項目，直接使用第一種方式進行修改會致使大量的警告，很容易一團糟；能夠經過編譯器指令對單文件或者單類進行修改操做，一點一點地修改。

2. 修改代碼

個人項目使用第一種方法的的狀況下有24個警告（編譯後有67個），也不知道算多仍是算少。

實體類

[DataContract]
    [Table("recordinfo")]
    public class RecordInfo : InfoBase
    {
        /// <summary>
        /// 記錄ID
        /// </summary>
        [DataMember]
        [Key]
        public string RecordNum { get; set; }
        /// <summary>
        /// 車輛RFID號碼
        /// </summary>
        [DataMember]
        public string CarID { get; set; }

RecordNum爲主鍵，經過EF進行映射，結果也不會爲null，因此聲明應該保持原樣便可。CarID不是主鍵，有多是null，所以應當顯式聲明爲string?，表示能夠爲空，刪除警告。

編譯器檢查，RecordNum沒有被初始化，咱們的設計意圖告訴編譯器了，可是代碼尚未保證這個不能爲空，所以須要修改代碼保證RecordNum不爲空。

這裏使用null包容運算符（！）來進行操做，提示編譯器這個位置實際上不會爲null。

//string的default爲null，經過增長！告訴編譯器，這塊初始化的時候其實是不爲空的。
public string RecordNum { get; set; } = default!;

null包容運算符並不能確保不是null，若是可使用代碼確保不爲null，那麼使用代碼會是更優選擇。考慮以下代碼：

//我常用String.IsNullOrWhiteSpace來進行檢查，空文本對個人業務沒有意義，所以適用。
public string RecordNum { get; set; } = "";

特別提示：
可爲空引用類型檢查是編譯器的行爲，它能夠提供編譯時檢查，可是不提供運行時檢查，若是使用外部代碼調用，那麼是否爲空均可以進行賦值。

很明顯，上面代碼運行時也很難保證不是null，咱們能夠再改進一下。

public string RecordNum
{
    get => recordNum;
    set => recordNum = value ?? "";
}
private string recordNum = "";

官方推薦對POCO類使用構造函數保證不爲空。
指定了default!的狀況，ASP.NET CORE WEBAPI會內部自動標註[Required]，遠程調用若是缺失參數，會提示bad request。

DataContext類

DataContext也是相似的，主要是DbSet對象的引用問題。

來自.NET Class Library

//BaseDirectory的返回是string?類型的
var baseDirectory = System.AppDomain.CurrentDomain.BaseDirectory;
//Path.Combine()不接受string?，提示錯誤。
var xmlPath = Path.Combine(baseDirectory, System.AppDomain.CurrentDomain.FriendlyName + ".xml");

這是一個潛在的bug點，對於以上代碼，很顯然BaseDirectory的返回爲null不符合咱們的設計，咱們能夠進行以下改造。

var baseDirectory = System.AppDomain.CurrentDomain.BaseDirectory;
if (baseDirectory == null) throw new ArgumentNullException("baseDirectory");
var xmlPath = Path.Combine(baseDirectory, System.AppDomain.CurrentDomain.FriendlyName + ".xml");

泛型類

public class ReturnData<T>
{
    //整個類型會提示Data未能初始化，ErrorMsg未能初始化。
    public ReturnData(){ }
    public ReturnData(T data) => Data = data;
    public ReturnData(string error) => ErrorMsg = error;
    /// <summary>
    /// 頁面數據
    /// </summary>
    public T Data { get; set; }
    public string ErrorMsg { get; set; }
}

設計意圖：Data與ErrorMsg不一樣時爲空，也不一樣時有值。

基於設計，能夠作以下修改。注意添加了class約束。

public class ReturnData<T>
    where T: class
{
    public ReturnData(){ }
    public ReturnData(T data) => Data = data;
    public ReturnData(string error) => ErrorMsg = error;
    /// <summary>
    /// 頁面數據
    /// </summary>
    public T? Data { get; set; }
    public string? ErrorMsg { get; set; }
}

其餘例子

using ManageDataContext context = new ManageDataContext();
var props = contextType.GetProperty($"{namestring}s");
//props提示有可能爲null
var dbset = (props.GetValue(context) as DbSet<T>);
//提示dbset可能爲null
var res = await dbset.FindAsync(value);

能夠調整爲下面的形式：

using ManageDataContext context = new ManageDataContext();
var props = contextType.GetProperty($"{namestring}s");
//判斷props能夠解決問題。
if (props == null) throw new ArgumentNullException("Props");
var dbset = (props.GetValue(context) as DbSet<T>);
//判斷dbset能夠解決問題。
if (dbset == null) throw new ArgumentNullException("dbset");
var res = await dbset.FindAsync(value);

注意，將as替換爲強制轉換，並不能消除警告。

總結

最後消除了全部的警告，改造結束。

這個新的語言特性能夠幫助咱們發現一些潛在的bug點，幫助咱們養成良好的編程習慣，也便於咱們告訴其餘人咱們的設計意圖。

編譯器能幫咱們作的工做，就不必本身再費勁作了，懶的不行，我得歇會兒。