爲何要使用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了嗎？^_^