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的分離問題

回答

相關問題