我沒有在項目中使用LINQ to SQL，我剛剛通過LINQ開發數據訪問邏輯的操作實驗，其中一項任務是創建實體轉換器類在linq實體和商業實體之間進行翻譯。LINQ實體與LINQ to SQL中的自定義實體
我對此有點困惑，因爲我認爲我們使用LINQ to SQL的原因是它可以爲我們自動生成LINQ實體，我們可以立即查詢/更新/插入/刪除實體。如果我們不必定義我們自己的自定義實體並且對我們的實體和LINQ實體之間的映射感到困擾，那將會很棒。但是，由於實驗室定義了商業實體，我知道我錯了。
有人能告訴我應該在什麼情況下定義業務實體，而不是立即使用實體LINQ to SQL嗎？在這種情況下使用LINQ to SQL來對抗ADO.Net有什麼好處？我期待您的回答，非常感謝！
使用LINQ實體將您綁定到數據持久性。對於很多應用來說，這沒什麼大不了的。但對於其他人來說，這是一個非常糟糕的設計。
例如，如果您的應用程序公開外部API以供客戶使用，那麼您不希望將持久性實體公開給客戶。否則，如果您需要更改數據模型（需求更改，調整性能以更大規模等），那麼您還將更改暴露的API。
對於許多大而複雜的項目，您希望在業務對象和數據持久性之間保持清晰的分隔。如果程序員和DBA在不同的團隊中並且做了非常不同的事情，情況尤其如此。他們應該在設計上一起工作，但編程邏輯和數據庫持久性是具有不同進步和侷限性的不同技術。他們之間的映射是他們如何溝通，但不應該受到另一方侷限的約束。
正如其他人所說，對於許多小型項目來說，這不是什麼大不了的事。如果你的應用程序只是數據的表單，並且數據相對簡單，並且直接關係不會改變，那麼LINQ類很好用。
你問一個很好的問題，這就是爲什麼很多人（包括我自己）覺得在L2S（或其他ORM）實體上構建一層業務對象是浪費時間。如果您需要完成這些步驟才能完成實驗（對於學校作業或類似的工作），那麼請執行此操作，但我不會將其推薦用於實際環境。
LINQ實體正好處理您的數據庫列。如果您的商業實體也這樣做，那麼很好，您可以直接使用LINQ實體（這是我通常所做的）。
如果您的業務規則需要更復雜的業務實體，則需要將它們映射到Linq實體。
這取決於你的數據。我曾與一些瘋狂的有機發展的數據庫，其中有很多未使用的列保留從其他應用程序的歷史查找（該死的SOX合規> =（）和許多其他問題
我們創建業務對象映射隱藏所有這些歷史性的疣，並提出一個乾淨的外觀代碼的其他領域。