linq-to-sql - 实体类从 LINQ 到 SQL 提供程序分离，用于实现存储库模式。如何？

Question

我查看了存储库模式，我发现了一些我过去使用的想法，这些想法让我感觉很好。

但是现在我想编写一个使用这种模式的应用程序 但我希望将实体类解耦 来自存储库提供程序。

我会创建几个程序集:

一个“接口(interface)”程序集，它将承载包括 IRepository 接口(interface)

在内的通用接口(interface)

一个“实体”程序集，它将承载产品、用户、订单等实体类。该程序集将由“接口(interface)”程序集引用，因为某些方法将返回此类类型或它们的数组。它也将被主应用程序程序集(例如 Web 应用程序)引用

一个或多个存储库提供程序程序集/程序集。每个都将包括(至少)一个实现 IRepository 接口(interface)的类，并且它将与某个数据存储一起使用。数据存储可以包括 SQL Server、Oracle 服务器、MySQL、XML 文件、Web/WCF 服务等。

在我发现生成的类和 CustomDataContext 类之间存在深度依赖之前，研究 LINQ to SQL 看起来在实现所有方面所花费的时间方面看起来非常有成效。

在这种情况下如何使用 LINQ to SQL？

Answer 1

我不知道这是否正是您想要的，但您可能想看看 Rob Conery 的 MVC Storefront 代码。他将存储库模式的变体与 linq 提供程序一起使用。他将 LINQ to Sql 对象映射到域对象，然后将域对象从存储库提供者返回到服务层，该服务层包装提供者，允许他在返回的数据到达业务层之前对其进行一些逻辑处理。

MVC Storefront Webcasts
Code

对我来说，听起来您希望提供者返回 DTO，然后您希望将 DTO 映射到存储库/服务层中的域对象。如果是这种情况，您可以将 LINQ to SQL 提供程序映射到 DTO，让它返回它们，然后将 DTO 映射到存储库/服务层中的域对象。这应该可以正常工作，但它可能会变得乏味，因为您现在将有 2 个映射层。

在这种情况下，您将拥有:
ProductService，它采用 IProductRepository。它调用 IProductRepository 上的方法来取回您的 DTO。然后它将 DTO 映射到真实的业务对象，并将它们返回给调用代码。