我是linq-to-sql（和sql）的新手，我開始收集證據，可能我沒有以正確的方式做事，所以我想看看你們都有什麼說。保持LINQ-to-SQL DataContext打開的時間要多長？
在我的員工分配應用程序中，我允許用戶在員工和項目之間創建分配。在應用程序開始時，我打開了一個linq-to-sql數據上下文到我的管理數據庫。在整個計劃中，我從不讓數據上下文流逝。事實上，大多數表單構造函數都將這個數據上下文作爲它們的參數之一。
我有點以爲這是做事情的方式，直到我讀完另一個SO問題，其中提問者在討論重複性地重新創建整個程序中的數據上下文，然後將實體「附加」到新的數據上下文中需要。這將幫助我解決我一直存在的問題，其中的事情是「偷偷」進入我的數據庫。
那麼你會在哪裏使用第一種風格（並且不要羞於說從不），並且你會在哪裏使用第二種風格？
如果您正在編寫一個Web應用程序（如ASP.NET MVC或Web服務），那麼您將每次都重新創建DataContext，因爲應用程序在頁面GET和POST之間是「無狀態的」。
如果您正在編寫Winforms或WPF應用程序，您可以按照相同的方式完成此操作，儘管保持打開DataContext可能會更容易，因爲Winforms應用程序是有狀態的（即，您有一個用於DataContext生存的容器） 。
一般來說，每次需要完成時打開一個DataContext可能是明智的。"unit of work." DataContext本身相當輕量級，因此爲每個「事務」打開一個並不是什麼大事。這種做法也與企業應用程序（即數據庫，DAL，服務層，存儲庫等）中的軟件層一致，並有助於強化所需層次之間的關注點分離。
一般推薦的做法是爲每個原子操作創建一個新的DataContext。 DataContext實際上很便宜，非常適合快速更新。作爲一般的經驗法則，我傾向於實例化DataContext，執行CRUD操作，然後再處置它。這可能是更新單個實體或插入一堆對象。做任何最適合你的場景的東西。
如果您要從上下文中傳遞實體，那麼請謹慎操作，因爲如果您嘗試枚舉或檢索相關數據，則會引發異常 - 最佳實踐是將LINQ實體轉換爲獨立對象（例如，Person LINQ實體可以轉換成一個PersonResult，它被你的解決方案的邏輯層使用）。
希望有幫助！