\

主要结论

\\

• 如果需要执行基本CURD之外的其他操作，此时就有必要使用仓储（Repository）。\\t
• 为了促进测试工作并改善可靠性，应将仓储视作可重复使用的库（Library）。\\t
• 将安全和审计功能放入仓储中可减少Bug并简化应用程序。\\t
• 对ORM的选择不会限制仓储的用途，只会影响仓储承担的工作量。\

在之前发布的文章中，我们介绍了实现仓储所需的基本模式。很多情况下，这些模式只是围绕底层数据访问技术，本质上并非完全必要的薄层。然而通过构建这样的仓储将获得很多新的机会。

在设计仓储时，需要从“必须发生的事”这个角度来思考。例如，假设制订了一条规则，每当一条记录被更新后，其“LastModifiedBy”列必须设置为当前用户。但我们并不需要在每次保存前更新应用程序代码中的LastModifiedBy，可以直接将相关函数放在仓储中。

通过将数据访问层视作管理所有“必须发生的事情”细节的独立库，即可大幅减少实现过程中的错误数量。与此同时可以简化基于仓储构建的代码，因为已经不再需要考虑“记账”之类的任务。

注意：本文会尽量提供适用于、和/或的代码范例，然而大部分仓储功能均可通过不依赖具体ORM的方式实现。

审计列

大部分应用程序最终需要追踪谁在什么时间更改了数据库。对于简单的数据库，这是通过审计列（Audit column）的形式实现的。虽然名称可能各不相同，但审计列通常主要承担下列四个角色：

• 创建者的User Key\\t
• 创建日期/时间\\t
• 最后修改者的User Key\\t
• 最后修改日期/时间\

取决于应用程序的安全需求，可能还存在其他审计列，例如：

• 删除者的User Key\\t
• 删除日期/时间\\t
• [创建 | 最后修改 | 删除] 者的Application Key\\t
• [创建 | 最后修改 | 删除] 者的IP地址\

从技术角度来看日期列很容易处理，但User Key的处理就需要费些功夫了，这里需要的是“可感知上下文的仓储”。

常规的仓储是无法感知上下文的，这意味着除了连接数据库时绝对必要的信息，仓储无法获知其他任何信息。如果能正确地设计，仓储可以是彻底无状态（Stateless）的，这样即可在整个应用程序中共享一个实例。

可感知上下文的仓储略微复杂。除非了解上下文，否则无法创建这种仓储，而上下文至少要包含当前活跃用户的ID和Key。对于某些应用程序这就够了，但对于其他应用程序，我们可能还需要传递整个用户对象和/或代表运行中应用程序的对象。

Chain

Chain通过一种名为审计规则（Audit rule）的功能为此提供了内建的支持。审计规则可供我们根据列名指定要覆盖（Override）的值。该功能包含了拆箱即用的基于日期的规则，以及从用户对象将属性复制到列的规则。范例：

\dataSource = dataSource.WithRules(\    new UserDataRule(\"CreatedByKey\