本文介绍从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了吗？^_