實體類的動態生成(二)

前言

因爲採用字典的方式來保存屬性變動值的底層設計思想,致使了性能問題,雖然.NET的字典實現已經很高效了,但相對於直接讀寫字段的方式而言依然有巨大的性能差距,同時也會致使對屬性的讀寫過程當中產生沒必要要的裝箱和拆箱。git

那麼此次咱們就來完全解決這個問題,同時還要解決「哪些屬性發生過變動」、「獲取變動的屬性集」這些功能特性,因此咱們先把接口定義出來,以便後續問題講解。github

/* 源碼位於 Zongsoft.CoreLibary 項目的 Zongsoft.Data 命名空間中 */

/// <summary> 表示數據實體的接口。</summary>
public interface IEntity
{
    /// <summary>
    /// 判斷指定的屬性或任意屬性是否被變動過。
    /// </summary>
    /// <param name="names">指定要判斷的屬性名數組,若是爲空(null)或空數組則表示判斷任意屬性。</param>
    /// <returns>
    ///        <para>若是指定的<paramref name="names"/>參數有值,當只有參數中指定的屬性發生過更改則返回真(True),不然返回假(False);</para>
    ///        <para>若是指定的<paramref name="names"/>參數爲空(null)或空數組,當實體中任意屬性發生過更改則返回真(True),不然返回假(False)。</para>
    ///    </returns>
    bool HasChanges(params string[] names);

    /// <summary>
    /// 獲取實體中發生過變動的屬性集。
    /// </summary>
    /// <returns>若是實體沒有屬性發生過變動,則返回空(null),不然返回被變動過的屬性鍵值對。</returns>
    IDictionary<string, object> GetChanges();

    /// <summary>
    /// 嘗試獲取指定名稱的屬性變動後的值。
    /// </summary>
    /// <param name="name">指定要獲取的屬性名。</param>
    /// <param name="value">輸出參數,指定屬性名對應的變動後的值。</param>
    /// <returns>若是指定名稱的屬性是存在的而且發生過變動,則返回真(True),不然返回假(False)。</returns>
    /// <remarks>注意:即便指定名稱的屬性是存在的,但只要其值未被更改過,也會返回假(False)。</remarks>
    bool TryGetValue(string name, out object value);

    /// <summary>
    /// 嘗試設置指定名稱的屬性值。
    /// </summary>
    /// <param name="name">指定要設置的屬性名。</param>
    /// <param name="value">指定要設置的屬性值。</param>
    /// <returns>若是指定名稱的屬性是存在的而且可寫入,則返回真(True),不然返回假(False)。</returns>
    bool TrySetValue(string name, object value);
}

設計思想

根本要點是取消用字典來保存屬性值迴歸到字段方式,只有這樣才能確保性能,關鍵問題是如何在寫入字段值的時候,標記對應的屬性發生過變動的呢?應用布隆過濾器(Bloom Filter)算法的思路來處理這個應用場景是一個完美的解決方案,由於布隆過濾器的空間效率和查詢效率極高,而它的缺點在此剛好能夠針對性的優化掉。算法

將每一個屬性映射到一個整型數(byte/ushort/uint/ulong)的某個比特位(bit),若是發生過變動則將該位置一,只要確保屬性與二進制位順序是肯定的便可,算法複雜度是O(1),而且比特位操做的效率也是極高的。數組

實現示範

有了算法,咱們寫一個簡單範例來感覺下:性能

public class Person : IEntity
{
    #region 靜態字段
    private static readonly string[] __NAMES__ = new string[] { "Name", "Gender", "Birthdate" };
    private static readonly Dictionary<string, PropertyToken<Person>> __TOKENS__ = new Dictionary<string, PropertyToken<Person>>()
    {
        { "Name", new PropertyToken<Person>(0, target => target._name, (target, value) => target.Name = (string) value) },
        { "Gender", new PropertyToken<Person>(1, target => target._gender, (target, value) => target.Gender = (Gender?) value) },
        { "Birthdate", new PropertyToken<Person>(2, target => target._birthdate, (target, value) => target.Birthdate = (DateTime) value) },
    };
    #endregion

    #region 標記變量
    private byte _MASK_;
    #endregion

    #region 成員字段
    private string _name;
    private bool? _gender;
    private DateTime _birthdate;
    #endregion

    #region 公共屬性
    public string Name
    {
        get => _name;
        set
        {
            _name = value;
            _MASK_ |= 1;
        }
    }

    public bool? Gender
    {
        get => _gender;
        set
        {
            _gender = value;
            _MASK_ |= 2;
        }
    }

    public DateTime Birthdate
    {
        get => _birthdate;
        set
        {
            _birthdate = value;
            _MASK_ |= 4;
        }
    }
    #endregion

    #region 接口實現
    public bool HasChanges(string[] names)
    {
        PropertyToken<Person> property;

        if(names == null || names.Length == 0)
            return _MASK_ != 0;

        for(var i = 0; i < names.Length; i++)
        {
            if(__TOKENS__.TryGetValue(names[i], out property) && (_MASK_ >> property.Ordinal & 1) == 1)
                return true;
        }

        return false;
    }

    public IDictionary<string, object> GetChanges()
    {
        if(_MASK_ == 0)
            return null;

        var dictionary = new Dictionary<string, object>(__NAMES__.Length);

        for(int i = 0; i < __NAMES__.Length; i++)
        {
            if((_MASK_ >> i & 1) == 1)
                dictionary[__NAMES__[i]] = __TOKENS__[__NAMES__[i]].Getter(this);
        }

        return dictionary;
    }

    public bool TryGetValue(string name, out object value)
    {
        value = null;

        if(__TOKENS__.TryGetValue(name, out var property) && (_MASK_ >> property.Ordinal & 1) == 1)
        {
            value = property.Getter(this);
            return true;
        }

        return false;
    }

    public bool TrySetValue(string name, object value)
    {
        if(__TOKENS__.TryGetValue(name, out var property))
        {
            property.Setter(this, value);
            return true;
        }

        return false;
    }
    #endregion
}

// 輔助結構
public struct PropertyToken<T>
{
    public PropertyToken(int ordinal, Func<T, object> getter, Action<T, object> setter)
    {
        this.Ordinal = ordinal;
        this.Getter = getter;
        this.Setter = setter;
    }

    public readonly int Ordinal;
    public readonly Func<T, object> Getter;
    public readonly Action<T, object> Setter;
}

上面實現代碼,主要有如下幾個要點:測試

  1. 屬性設置器中除了對字段賦值外,多了一個位或賦值操做(這是一句很是低成本的代碼);
  2. 須要一個額外的整型數的實例字段 _MASK_ ,來標記對應更改屬性序號;
  3. 分別增長 __NAMES__ __TOKENS__ 兩個靜態只讀變量,來保存實體類的元數據,以便更高效的實現 IEntity 接口方法。

根據代碼可分析出其理論執行性能與原生實現基本一致,內存消耗只多了一個字節(若是可寫屬性數量小於9),因爲 __NAMES____TOKENS__ 是靜態變量,所以不佔用實例空間,理論上該方案的總體效率很是高。優化

性能對比

上面咱們從代碼角度簡單分析了下整個方案的性能和消耗,那麼實際狀況到底怎樣呢?跑個分唄(性能對比測試代碼地址:https://github.com/Zongsoft/Zongsoft.CoreLibrary/tree/feature-data/samples/Zongsoft.Samples.Entities),具體代碼就不在這裏佔用版面了,下面給出某次在個人老舊臺式機(CPU:Intel i5-3470@3.2GHz | RAM:8GB | Win10| .NET 4.6)上生成100萬個實例的截圖:ui

<div data-type="alignment" data-value="center" style="text-align:center">
<div data-type="p">this

<div id="l3wopz" data-type="image" data-display="block" data-align="" data-src="https://cdn.yuque.com/yuque/0/2018/png/86907/1531714549493-133f1ae1-2ef7-4109-8e85-28762ad3c803.png" data-width="356">
  <img src="https://cdn.yuque.com/yuque/0/2018/png/86907/1531714549493-133f1ae1-2ef7-4109-8e85-28762ad3c803.png" width="356" />
</div>

</div>
</div>spa

  • 「Native Object: 295」表示原生實現版(即簡單的讀寫字段)的運行時長(單位:毫秒,下同);
  • 「Data Entity: 295」爲本案的運行時長,一般本方案比原生方案要慢10毫秒左右,偶爾能跑平(屬於運行環境抖動,可忽略);
  • 「Data Entity(TrySet): 835」爲本方案中 TrySet(...) 方法的運行時長,因爲 TrySet(...) 方法內部須要進行字典查詢因此有性能損耗亦屬正常,在百萬量級跑到這個時長說明性能也是很不錯的,若是切換到 .NET Core 2.1 的話,得益於基礎類庫的性能改善,還能再享受一波性能紅利。

綜上所述,該方案付出極少的內存成本得到了與原生簡單屬性訪問基本一致的性能,同時還提供了屬性變動跟蹤等新功能(即高效完成了 Zongsoft.Data.IEntity 接口中定義的那些重要功能特性),爲後續業務開發提供了有力的基礎支撐。

實現完善

上面的實現範例代碼並無實現 INotifyPropertyChanged 接口,下面補充完善下實現該接口後的屬性定義:

public class Person : IEntity, INotifyPropertyChanged
{
    // 事件聲明
    public event PropertyChangedEventHandler PropertyChanged;

    public string Name
    {
        get => _name;
        set
        {
            if(_name == value)
                return;

            _name = value;
            _MASK_ |= 1;
            this.PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Name)));
        }
    }
}

如上,屬性的設置器中的作了一個新舊值的比對判斷和對 PropertyChanged 事件激發,其餘代碼沒有變化。

另外,咱們使用的是 byte 類型的 _MASK_ 的標記變量來保存屬性的更改狀態,若是當實體的屬性數量超過 8 個,就須要根據具體數量換成相應的 UInt16,UInt32,UInt64 類型,但若是超過 64 就須要採用 byte[] 了,固然必需要變更下相關代碼,假設如下實體類有 100 個屬性(注意僅例舉了第一個 Property1 和最後一個 Property100 屬性):

public class MyEntity : IEntity
{
    #region 標記變量
    private readonly byte[] _MASK_;
    #endregion

    public Person()
    {
        _MASK_ = new byte[13]; // 13 = Math.Ceiling(100 / 8)
    }

    public object Property1
    {
        get => _property1;
        set
        {
            _property1 = value;
            _MASKS_[0] |= 1; // _MASK_[0 / 8] |= (byte)Math.Pow(2, 0 % 8);
        }
    }

    public object Property100
    {
        get => _property100;
        set
        {
            _property100 = value;
            _MASKS_[12] |= 8; // _MASK_[99 / 8] |= (byte)Math.Pow(2, 99 % 8);
        }
    }
}

變化內容爲先根據當前屬性的順序號來肯定到對應的標記數組的下標,而後再肯定對應的掩碼值。固然,也別忘了調整 Zongsoft.Data.IEntity 接口中各方法的實現。

public class MyEntity : IEntity
{
    public bool HasChanges(params string[] names)
    {
        PropertyToken<UserEntity> property;

        if(names == null || names.Length == 0)
        {
            for(int i = 0; i < _MASK_.Length; i++)
            {
                if(_MASK_[i] != 0)
                    return true;
            }

            return false;
        }

        for(var i = 0; i < names.Length; i++)
        {
            if(__TOKENS__.TryGetValue(names[i], out property) && (_MASK_[property.Ordinal / 8] >> (property.Ordinal % 8) & 1) == 1)
                return true;
        }

        return false;
    }

    public IDictionary<string, object> GetChanges()
    {
        var dictionary = new Dictionary<string, object>(__NAMES__.Length);

        for(int i = 0; i < __NAMES__.Length; i++)
        {
            if((_MASK_[i / 8] >> (i % 8) & 1) == 1)
                dictionary[__NAMES__[i]] = __TOKENS__[__NAMES__[i]].Getter(this);
        }

        return dictionary.Count == 0 ? null : dictionary;
    }

    public bool TryGet(string name, out object value)
    {
        value = null;

        if(__TOKENS__.TryGetValue(name, out var property) && (_MASK_[property.Ordinal / 8] >> (property.Ordinal % 8) & 1) == 1)
        {
            value = property.Getter(this);
            return true;
        }

        return false;
    }

    public bool TrySetValue(string name, object value)
    {
        /* 相對以前版本沒有變化 */
        /* No changes relative to previous versions */
    }
}

代碼變化部分比較簡單,只有掩碼處理部分須要調整。

新問題

有了這些實現範式,定義個實體基類並在基類中完成主要功能便可推廣應用了,可是,這裏有個掩碼類型和處理方式沒法通用化實現的問題,若是要把這部分代碼交由子類來實現的話,那麼代碼複用度會大打折扣甚至徹底失去複用的意義。

爲展現這個問題的艱難,在 https://github.com/Zongsoft/Zongsoft.CoreLibrary/blob/feature-data/tests/Entities.cs 源文件中,寫了屬性數量不等的幾個實體類(Person、Customer、Employee、SpecialEmployee),採用繼承方式進行復用性驗證,可清晰看到實現的很是冗長繁瑣,對實現者的細節把控要求很高、實現上很是容易出錯,更致命的是複用度還極差。而且當實體類須要進行屬性增減,是很是麻煩的,須要仔細調整原有代碼結構中掩碼的映射位置,這對於代碼維護無心是場惡夢。

新辦法

解決辦法其實很簡單,正是本文的標題——「動態生成」,完全解放實現者並確保實現的正確性。業務方再也不定義具體的實體類,而是定義實體接口便可,實體類將由實體生成器來動態生成。咱們依然「從場景出發」,先來看看業務層的使用。

public interface IPerson : IEntity
{
    string Name { get; set; }
    bool? Gender { get; set; }
    DateTime Birthdate { get; set; }
}

public interface IEmployee : IPerson
{
    byte Status { get; set; }
    decimal Salary { get; set; }
}

var person = Entity.Build<IPerson>();
var employee = Entity.Build<IEmployee>();

總結

至此,終於獲得了一個兼顧性能與功能並易於使用且無需繁瑣的手動實現的最終方案,雖然剛開始看起來是一個多麼日常又簡單的任務。那麼接下來咱們該怎麼實現這個動態生成器呢?最終它能性能無損的被實現出來嗎? 請關注咱們的公衆號(Zongsoft)留言討論。

提示

本文可能會更新,請閱讀原文: https://zongsoft.github.io/blog/zh-cn/zongsoft/entity-dynamic-generation-2,以免因內容陳舊而致使的謬誤,同時亦有更好的閱讀體驗。


知識共享許可協議

本做品採用 知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議 進行許可。歡迎轉載、使用、從新發布,但必須保留本文的署名 鍾峯(包含連接:http://zongsoft.github.io),不得用於商業目的,基於本文修改後的做品務必以相同的許可發佈。若有任何疑問或受權方面的協商,請致信給我 (zongsoft@qq.com)。

相關文章
相關標籤/搜索