将问题与Linq To SQL和DTO分开

我最近开始了一个新的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),以及随着项目的进展可能会遇到的其他问题.

1> BirgerH..：

---

我不知道这是不是最好的做法,但是我在最近的一段时间里编写了类似的代码,因为我觉得我可以通过在我的应用程序中使用自己的类而不是LINQ设计器生成的类来改善关注点的分离.

您可能想要考虑从数据访问方法返回IQueryable 而不是IList .由于IQueryable 继承自IEnumerable ,因此应用程序的其余部分应该能够很好地处理它.您还可以在需要时将其转换为List.

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

例如,如果您的方法签名是IQueryable GetCustomers(),您可以通过调用GetCustomers()获得单个客户.其中(c => c.CustomerID == 101).Single();

在这个例子中,只有一条记录会从数据库中返回,而我想现在你的代码会返回所有客户,或者你需要编写单独的方法(因此非常重复的代码)来满足你可能想要的所有不同的东西.过滤.

---

我建议完全相反.我不会在DAL之外的IList上返回IQuerable.如果这样做,那么您的表示层可能会无意中最终执行数据库查询,或者您可能最终混合使用Linq-to-objects调用并获得Linq-to-sql错误.从Linq-to-sql返回IQuerable会导致一个非常糟糕和漏洞的架构,应该避免除了最肮脏的玩具应用程序之外的所有应用程序.