为什么要使用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了吗?_
如果觉得这篇文章对你有帮助的话,记得点击一下
“推荐”,我在此感谢~
如果觉得点了“推荐”还不够,那么点击“赞赏”,请我喝 一瓶肥宅快乐水 或 一杯咖啡 ,那真是极好的(๑•̀ㅂ•́)و✧
本文作者: 苏格拉底粉
版权声明: 本博客所有文章除特别声明外,均采用
CC BY-NC-SA 4.0 许可协议。转载请注明出处!