為什麼要使用Entity Framework

摘要： 本文介紹從DDD(Domain-Driven Design[領域驅動設計])的角度來說說為什麼要使用Entity Framework(以下都會簡稱為EF)，同時也看出類似Drapper之類的簡陋ORM不足的地方。 設想業務都是大家知曉的許可權管理，實體類如下。 public parti...

本文介紹從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了嗎？^_^