向来有争议的话题都是公说公的理，婆说婆的理，Entity Framework的爱好者对此可以说是嗤之以鼻，不屑一顾，而Dapper爱好者则是举双手赞成，阅之大快人心。
每个人不同的阅历，社会经验，甚至对简繁的偏见都会影响对此事的看法，凡事都有优劣，取其精华而弃之糟泊，方为上策。
这篇文章则将目光聚焦到Dapper。
Dapper是如此的简单，她只提供了 3 个帮助函数：
执行一个查询，将结果映射到一个强类型列表
执行一个查询，将结果映射到一个动态对象列表
执行一个命令，不返回结果
而在实际的项目中，我们可能只会用到强类型列表，所以上面列出的 3 个帮助函数只会用到 2 个。
有人说了，简单其实就意味着复杂，的确如此。
过少的封装意味着每次可能要书写过多的重复代码，因此每个Dapper开发者可能都会自行扩展一些用着顺手的方法，也就不足为奇了，俗话说一千个人眼里有一千个哈姆雷特。
下面我会分享在将 AppBoxPro 从 EntityFramework 迁移到 Dapper 中遇到的问题，以及解决方法，其中也包含我的小小封装，希望你能喜欢。
下面是 AppBoxPro.Dapper 的项目开发截图：
提醒：文末免费下载价值 109 元的 AppBoxPro.Dapper 的全部源代码，仅限 2018-09-10/11 两天，莫失莫忘！
正文 模型的约定我们对模型有两个约定：
1. IKeyID接口
2. NotMapped特性
来看一下 User 模型的声明：
public class User : IKeyID { [Key] public int ID { get; set; } [Required, StringLength(50)] public string Name { get; set; } [Required, StringLength(100)] public string Email { get; set; } public int? DeptID { get; set; } [NotMapped] public string UserDeptName { get; set; } }