Linq To SQL和DTO的分离问题

我最近启动了一个新的webforms项目，并决定将业务类与任何DBML引用分开。我的业务层类访问离散的数据层方法，并且是DTO的返回集合。因此，数据层可以投射DTO的类似如下：Linq To SQL和DTO的分离问题

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

虽然建立DTO对象增加了工作，这种感觉就像一个更好的方法，以紧密结合业务&之间的数据层和意味着我可以测试业务层，而不一个数据库存在。

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

来源

2008-09-09 Sean Campbell

我已经发布了一些关于外部XML映射的链接：http://stackoverflow.com/questions/988872/linq-to-sql-external-mapping/1136039#1136039 – alexandrul 2009-07-16 07:58:29

我不知道这是否是最佳实践，但是我在近期并没有写出类似的代码，因为我也觉得我可以通过使用自己的类而不是LINQ设计器生成的类来改善关注点分离在我的应用程序内。

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

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

E.g.如果您的方法签名是 IQueryable <Customer> GetCustomers（）您可以通过调用GetCustomers（）来获得单个客户。

在这个例子中，只有一条记录会从数据库中返回，而我想现在你的代码会返回所有的客户，或者你会被要求编写单独的方法（因此是非常重复的代码）来迎合所有不同的你可能想过滤的东西。

来源

2008-09-09 03:54:51 BirgerH

我建议完全相反。我不会在DAL之外的IList上返回IQuerable。如果这样做，那么表示层可能最终会无意中执行数据库查询，或者最终可能会混合Linq到对象的调用并获得Linq-to-sql错误。从Linq-to-SQL返回IQuerable使得构建一个非常糟糕和漏洞的体系结构，除了最简单的玩具应用程序之外，都应该避免使用它。 – mattmc3 2010-10-12 01:52:49

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

来源

2008-09-09 03:45:02 aku

同意。实质上，你的Linq-to-sql对象可以被当作DTOs，甚至还有一个T4模板用于生成可序列化的L2S对象。 – mattmc3 2010-10-12 01:54:22

Linq To SQL和DTO的分离问题

回答

相关问题