11

我最近开始了一个新的 webforms 项目，并决定将业务类与任何 DBML 引用分开。我的业务层类改为访问离散的数据层方法，并返回 DTO 的集合。所以数据层可能会像下面这样投射 DTO：

(from c in dataContext.Customers
where c.Active == true 
select new DTO.Customer
{
   CustomerID = c.CustomerID,
   Name = c.CustomerName,
   ...
}).ToList()

尽管构建 DTO 对象会增加工作量，但这感觉像是在业​​务层和数据层之间紧密绑定的更好方法，这意味着我可以在没有数据库的情况下测试业务层。

我的问题是，这是一种好的做法吗？，有没有一种方法可以生成 DTO（可能通过 SQLMetal），以及随着项目的进展我可能会遇到哪些其他问题。

4

2 回答 2

5

我不知道这是否是最佳实践，但我在不久前编写了类似的代码，因为我也觉得我可以通过在我的应用程序中使用我自己的类而不是 LINQ 设计器生成的类来改进关注点分离.

您可能需要考虑从数据访问方法中仅返回 IQueryable<Customer> 而不是 IList<Customer>。由于 IQueryable<T> 继承自 IEnumerable<T> ，因此您的应用程序的其余部分应该能够很好地处理它。您也可以在真正需要时将其转换为列表。

这样做的好处是您可以很容易地动态修改查询并最大限度地减少从 SQL Server 返回的数据量。

例如，如果您的方法签名是 IQueryable<Customer> GetCustomers() 您可以通过调用 GetCustomers().Where(c => c.CustomerID == 101).Single();

在此示例中，只会从数据库返回一条记录，而我想目前您的代码将返回所有客户，或者您需要编写单独的方法（因此是非常重复的代码）来满足您可能想要的所有不同事物过滤。

于 2008-09-09T03:54:51.950 回答
2

在我看来，在大多数情况下，处理 LINQ 时不需要 DTO 对象。生成的 LINQ 类可以轻松测试。LINQ 使您能够使用相同的查询来查询来自不同来源的数据。它使您能够针对对象列表而不是真实数据库来测试您的查询。

于 2008-09-09T03:45:02.847 回答