为什么要使用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了吗?^_^

posted @ 2018-09-13 13:50  iDream  阅读(...)  评论(... 编辑 收藏