DAO（数据访问对象）是 .NET 中常用的模式吗？我一直使用 DAO 作为提供对我的数据层的访问的一种方式。例如，我的 EntityFramework ObjectContext 上可能有一个薄接口，将我的所有 ObjectSet 暴露为 IObjectSet。
然后 DAO 将公开复杂的查询，每个 DAO 都依赖于该接口。我可能有一个 ProductDAO，它公开了 GetProductsOnSale() 或 GetInfrequenlySoldProducts() 之类的方法。然后，我的控制器或演示者将使用这些方法，这些方法可能是虚拟的，以允许对单元测试的特定结果进行存根。
那么这是 .NET 中常用的习语吗？出于某种原因，我在网上看到的绝大多数使用这种模式的示例都是基于 Java 的。即使是关于 DAO 最佳实践的 this question 也被标记为 Java 而不是 C#。
使用其他社区的东西并没有错，我只是有点担心我周围的每个人都在做不同的事情......
【问题讨论】：
这是 .NET 中的一个常见习语。我用过，也见过很多地方用过。
它内置在框架中 - 请参阅 System.Data 命名空间 - 许多类是专用提供程序（SQL Server、Oracle、MySQL 等）的基类，并且在基类上执行操作。
但是，您所描述的内容在我看来更像是 Repository Pattern，而不是简单地使用 Data Access Objects。
这也用于许多项目中，但未内置到框架中。
【讨论】：
IObjectSet<T> 成员的“东西”，DAO 是使用存储库构建查询的类。这与您使用这些术语的方式一致吗？
DAO 是 抽象 实际的 DB 接口，Repository 是抽象使用 DAO 来表示一个应该是“内存中”的集合。
我广泛使用 DAO 模式。
您提到了实体框架；除此之外，我要补充一点，我发现 DAO 比 DataSets 和 DataTables 好得多，它们太像数据库了，不像我喜欢的对象。例如，不能将 DataRows 添加到多个数据表中，因此我无法将加载的数据的子集传递给不同的对象，除非将它们移动到不是为包含它们而构建的容器中。 （即，DataRow 似乎应该在 DataTable 中，但它们一次只能在一个 DataTable 中。）DataRowView 很笨重，不如将实体对象添加到另一个列表那么直观。
【讨论】：
对于使用存储库模式来封装数据访问（这确实是一个非常好的模式），我最大的建议是能够创建一个通用存储库。但是要创建一个非常智能的通用存储库，它可以让您基本上实时连接以立即访问所有标准 CRUD 操作，以及访问复杂的查询构造，您不会暴露给您ISomeService 外观。
使用通用存储库最重要的一点是，您希望它基于构造函数注入，而不是基于继承。通过这种方式，您可以编写 SomeService 以依赖于实现有意义的业务域边界所需的许多通用存储库。
我就这个概念写了一篇深入的博客。 Creating a common generic and extensible NHiberate Repository version 2。虽然这篇博文专门针对 NHibernate 的引用，但您可以采用相同的核心概念并将它们应用于几乎任何 DAO。
注意一些工具，例如 Entity Framework、Linq2Sql 和 RavenDB 等等，它们本身公开了非常精炼的存储库，可能不一定会从添加额外的包装器中受益。
【讨论】：