原文：https://msdn.microsoft.com/en-us/library/ff649690.aspx
Context:
在很多应用程序中，业务逻辑从数据存储(例如数据库，web)中访问数据，直接访问数据可能会造成这样的后果：
1.重复编码
2.编程错误的可能性增大
3.弱类型的业务数据//强弱类型的区别就是类型安全检查，内存检查，动态 静态类型检查
4.难以集中管理数据相关的策略（如缓存）
5.难以让业务逻辑隔离外部依赖去进行测试
解决方法：
Use a repository to separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model（使用仓库将检索数据和实体模型的映射与作用于实体的的业务逻辑分离）.业务逻辑应该与包含此数据的数据层实现无关，比如说，数据层可以是数据库，一个网络服务等。
程序中的repository应该是在数据层和业务逻辑层中间，它从数据层查询数据，将数据从数据源映射到业务实体，并将业务实体的更改保留到数据源。存储库将业务逻辑与与底层数据源或Web服务的交互分离。数据层和业务层之间的分离有三个好处：
1.集中了数据逻辑或web服务访问逻辑
2.It provides a substitution point for the unit tests.（为单元测试提供了一个替代点）
3.提供了一种灵活的架构，可以随着程序的整体设计的发展而进行调整
repository有两种方法去查询业务实体：
1.它可以向客户端的业务逻辑提交查询对象
2.他可以使用指定业务标准的方法
在第二种情况下，repository代表客户端进行查询。repository返回一组满足查询的实体集合。下图显示了repository与客户端和数据源的交互：
客户端为了实现持久性存储给repository提交新的或更改过的实体，在复杂的情况下，客户端业务逻辑可以使用工作单元模式，这种模式展示了如何封装彼此一致或具有相关依赖关系的几个相关操作。已经封装好的项会被发送到repository去进行更新或删除，本指南不包括工作单元模式的示例。
repository是不同的域(domain)中数据和操作之间的桥梁。
一个常见的例子就是将一个弱类型数据的域（数据库，SharePoint list）映射到一个强数据类型的域中（域中实体模型）。
一个典型的例子就是数据库使用IDbCommand对象执行查询并返回一个IDataReader的对象.
另一个例子就是SharePoint,使用SPQuery对象去返回SPListItem的集合。repository向数据源发出正确的查询，查询结束后将结果集映射到外部的业务实体。repository通常使用Data Mapper(数据映射)模式在表示层之间进行转换。它移除了客户端对指定技术的依赖关系。比如说，如果客户端调用目录仓库去获取产品数据，它只需要调用仓库的商品目录接口（catalog repository interface）。再比方说，客户端不需要知道商品信息是通过SQL查询语句从数据库中查询的还是通过协作应用标记语言（Collaborative Application Markup Language (CAML)）从Sharepoint列表查询的。隔离这些类型的依赖性提供了一种实现的灵活性。
实施细节：
这部分论述了SharePoint列表库和Web服务库的实现策略.
SharePoint:
此部分略。与安卓无关。
Web服务库：
一个常见的数据后台存储是由line-of-business(LOB)应用程序公开的商业服务。通常来说，这些商业服务是对于普通数据库CRUD操作更高层次的抽象。然而，从客户端的角度来说，
他们通常等同于数据源。与SharePoint列表相似，访问网络服务可以是复杂并且容易出错的。通过使用repository集中访问服务的逻辑并且提供一个单元测试的替代点。请注意，服务的调用通常很昂贵，并且受益于在repository实现的缓存策略。（也就是通过本地缓存减少服务的调用）
下图展示了使用缓存的服务后端存储库：
在这种情况下，repository的查询逻辑先检查缓存中是否有需要的数据，如果没有，repository访问网络服务区获取信息。虽然可以直接访问服务，但也可以通过SharePoint的业务数据目录去访问（SharePoint Business Data Catalog (BDC)）。BDC可以合并一些数据源（包括网络服务），然后通过统一通用的接口暴露它们。BDC允许你去使用标准的网络不见去展示或修改数据。
Repository Examples：
略。
注意事项：
Repository模式增加了你代码中的抽象层次。这会导致你的代码难以被你的同事去理解，尽管实现该模式减少了代码冗余，但他通常会增加需要被维护的类的数量。
Repository模式帮助我们去隔离服务和列表访问的代码。通过这种隔离，更容易将它们视为独立的服务，并在单元测试当中用模拟对象去替代它们。通常来说，很难对repository本身进行单元测试，所以尽量去为他们编写集成测试。
当你在多线程环境中缓存数据时，除了缓存对象之外，还要考虑同步对缓存的访问呢。一般来说，常见缓存（ASP.NET的缓存），是线程安全的，但你也要确保对象自身可以在多线程环境中操作。
如果你在高负载系统中缓存数据，性能可能是一个问题，尝试对数据源进行同步访问，这确保了只有单个数据请求被发送到列表或后台服务。其他的客户端依赖于检索的数据。