0x00 前言
之前一直使用的是 EF ，做了一个简单的小项目后发现 EF 的表现并不是很好，就比如联表查询，因为现在的 EF Core 也没有啥好用的分析工具，所以也不知道该怎么写 Linq 生成出来的 Sql 效率比较高，于是这次的期末大作业决定使用性能强劲、轻便小巧的 ORM —— Dapper。
0x01 Repository 模式
Repository 模式几乎出现在所有的 asp.net 样例中，主要的作用是给业务层提供数据访问的能力，与 DAL 的区别就在于：
Repository模式：
Repository 是DDD中的概念,强调 Repository 是受 Domain 驱动的， Repository 中定义的功能要体现 Domain 的意图和约束,而 Dal 更纯粹的就是提供数据访问的功能,并不严格受限于 Business 层。使用 Repository ，隐含着一种意图倾向，就是 Domain 需要什么我才提供什么,不该提供的功能就不要提供，一切都是以 Domain 的需求为核心。
而使用Dal，其意图倾向在于我 Dal 层能使用的数据库访问操作提供给 Business 层，你 Business 要用哪个自己选.换一个 Business 也可以用我这个 Dal，一切是以我 Dal 能提供什么操作为核心.
0x02 TDD（测试驱动开发）
TDD 的基本思路就是通过测试来推动整个开发的进行。而测试驱动开发技术并不只是单纯的测试工作。
在我看来，TDD 的实施可以带来以下的好处：
- 在一个接口尚未完全确定的时候，通过编写测试用例，可以帮助我们更好的描述接口的行为，帮助我们更好的了解抽象的需求。
- 编写测试用例的过程能够促使我们将功能分解开，做出“高内聚，低耦合”的设计，因此，TDD 也是我们设计高可复用性的代码的过程。
- 编写测试用例也是对接口调用方法最详细的描述，Documation is cheap, show me the examples。测试用例代码比详尽的文档不知道高到哪里去了。
- 测试用例还能够尽早的帮助我们发现代码的错误，每当代码发生了修改，可以方便的帮助我们验证所做的修改对已经有效的功能是否有影响，从而使我们能够更快的发现并定位 bug。
0x03 建模
在期末作业的系统中，需要实现一个站内通知的功能，首先，让我们来简单的建个模：
然后，依照这个模型，我创建好了对应的实体与接口：
1 public interface IInsiteMsgService 2 { 3 /// <summary> 4 /// 给一组用户发送指定的站内消息 5 /// </summary> 6 /// <param name="msgs">站内消息数组</param> 7 Task SentMsgsAsync(IEnumerable<InsiteMsg> msgs); 8 9 /// <summary> 10 /// 发送一条消息给指定的用户 11 /// </summary> 12 /// <param name="msg">站内消息</param> 13 void SentMsg(InsiteMsg msg); 14 15 /// <summary> 16 /// 将指定的消息设置为已读 17 /// </summary> 18 /// <param name="msgIdRecordIds">用户消息记录的 Id</param> 19 void ReadMsg(IEnumerable<int> msgIdRecordIds); 20 21 /// <summary> 22 /// 获取指定用户的所有的站内消息，包括已读与未读 23 /// </summary> 24 /// <param name="userId">用户 Id</param> 25 /// <returns></returns> 26 IEnumerable<InsiteMsg> GetInbox(int userId); 27 28 /// <summary> 29 /// 删除指定用户的一些消息记录 30 /// </summary> 31 /// <param name="userId">用户 Id</param> 32 /// <param name="insiteMsgIds">用户消息记录 Id</param> 33 void DeleteMsgRecord(int userId, IEnumerable<int> insiteMsgIds); 34 }