我最近开始了一个新的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)，以及随着项目的进行我还会遇到什么其他问题？

解决方案

回答

在我看来，在大多数情况下，处理LINQ不需要DTO对象。生成的LINQ类可以很容易地进行测试。 LINQ使我们能够使用相同的查询来查询来自不同来源的数据。它使我们能够针对对象列表而不是实际数据库测试查询。

回答

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

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

这样做的好处是，我们可以非常轻松地动态修改查询，并最大程度地减少从SQL Server返回的数据量。

例如。如果方法签名是
IQueryable <Customer> GetCustomers()，我们可以通过调用GetCustomers()获得单个客户。where(c => c.CustomerID == 101).Single();

在此示例中，数据库中仅返回一条记录，而我想象当前代码将返回所有客户，或者我们将需要编写单独的方法(因此是非常重复的代码)来满足我们可能需要的所有不同内容过滤。