Question

在使用IRepository<>的Orchard CMS中非常常见。

所以我问自己，使用IRepository<>及其Fetch()方法而不是简单地使用Linq to SQL查询数据有什么好处？

IRepository＆LT;＆GT;

Repository.Fetch(r => r.ID == 1234).Select(r => r.Name)

这里的缺点是我必须在构造函数中注入存储库。

Linq to SQL

from r in Repository where r.ID == 1234 select r.Name

Answer 1

通常，存储库是数据访问代码之上的抽象。您可能有多个IRepository接口实现，一个使用LINQ to SQL作为数据访问技术，另一个使用Raw ADO.NET或另一个使用XML文件作为数据存储。使用此存储库抽象，您访问数据的前端代码（例如：repository.GetCustomer(someId)）保持不变。我们可以根据需要简单地实现实现。

拥有此抽象允许您为代码编写单元测试。您只需要创建IRepository的模拟实现。您可以使用像Moq这样的模拟库来实现这一目标。

使用Moq

的单元测试代码的快速示例

var repo= new Mock<IRepository>();
var dummyCustomer = new Customer { Name ="Test"}
repo.Setup(s=>s.GetCustomer(It.IsAny<int>).Returns();

var customerMgr = new CustomerManager(repo.Object);
var actualResult = customerMgr.GetCustomer(345);

//Assert something now.

此处运行单元测试时，它不会命中数据库，而是会返回dummyCustomer

Answer 2

我同意Bertrand的观点，你应该总是使用IContentManager来获取数据库内容，但是我可以想到使用IRepository＆lt;＆gt;的唯一一种用法。而不是IContentManager仅用于基于记录的项目，即没有部分的记录，在这种情况下，对它们执行db操作的唯一方法是通过IRepository

Answer 3

在Orchard的背景下，你通常不应该使用它们。存储库是一个几乎不应该使用的实现细节（参见https://weblogs.asp.net/bleroy/just-forget-that-repository-t-exists-please）。 Linq to SQL被废弃的ORM技术从未成为Orchard的一部分。 Orchard使用nHibernate，最好的办法是直接使用nHibernate Session进行低级数据库访问，并使用Content Manager API进行更高级别的查询。

Orchard IRepository vs. Linq to SQL

3 个答案: