為什麼要使用Entity Framework

本文介紹從DDD(Domain-Driven Design[領域驅動設計])的角度來說說為什麼要使用Entity Framework(以下都會簡稱為EF)，同時也看出類似Drapper之類的簡陋ORM不足的地方。

設想業務都是大家知曉的許可權管理，實體類如下。

public partial class User
{
    /// <summary>
    /// 用戶名
    /// </summary>
    public string Username { get; set; }

    /// <summary>
    /// 用戶密碼
    /// </summary>
    public string Password { get; set; }

    public virtual ICollection<Role> Roles { get; set; }
}

public partial class Role
{
    /// <summary>
    /// 角色ID
    /// </summary>
    public int ID { get; set; }

    /// <summary>
    /// 角色名稱
    /// </summary>
    public string Name { get; set; }
}

讀到這裡，請先思考一下，給一個 User 添加一個新的 Role ，你會怎麼寫代碼？，然後再接下去看看DDD認為應該怎麼寫。

//上面的User類，只是對資料庫做簡單映射的模型，在DDD思想中也稱為 貧血模型
//接下來，我們把User類變成一個真正的 領域模型，也就是說 領域模型 會包含有業務邏輯！
public partial class User
{
    /// <summary>
    /// 給用戶添加一個新的角色
    /// </summary>
    /// <param name="role"></param>
    public void AddRole(Role role)
    {
        //業務邏輯：先判斷該用戶是否已經擁有該角色，沒有才能添加。
        if (!this.Roles.Any(x => x.ID == role.ID))
        {
            this.Roles.Add(role);
        }
        //這裡的代碼是Ado.Net，Drapper之類是做不到這樣的。
        //所以要實現DDD，必須配上EF之類的強大的ORM。
    }
}

接下來，我們來看看怎麼調用，可以看出一切都是圍繞User這個領域模型的。

var user = userService.GetUserById(userId);
user.AddRole(role);//可以看出用了領域模型後，代碼更加OOP了~
userService.Update(user);

更加理想的DDD，是連userService都不要，但目前很難實現這種做法。

var user = User.Init(userId);
user.AddRole(role);
user.SaveChange()

理想很豐滿，現實很骨感，除了技術不能完全實現DDD的思想，我們還要考慮性能問題，
所以目前的DDD的做法是推薦搜索功能，也就是說搜索出現的數據作展示用，不會再對搜索出來的數據進行增刪改，那麼就怎麼快怎麼來。你愛用Drapper也行，用EF+原生Sql也行，用Ado.Net也行。

不是說面向過程化的思想不行，能抓老鼠的就是好貓。
但前輩們的經驗是，面對複雜的業務，用DDD的思想來解決會更好。

所以
今天你OOP，DDD了嗎？^_^