這個問題是針對LINQ to SQL .dbml best practices這個問題的程度，但我不確定如何添加到問題。管理LINQ to SQL .dbml模型的複雜性
我們的一個應用程序使用LINQ to SQL，並且目前我們有一個用於整個數據庫的.dbml文件，這個文件變得難以管理。我們正在考慮將它重構成一些單獨的文件，這些文件是特定於模塊/功能的，但是一個問題是許多高級類必須在幾個.dbml文件中重複，因爲這些關聯不能跨越使用。 dbml文件（據我所知），以及額外的部分類代碼。
有沒有人在解決這個問題，你會提出什麼建議？
我們用它來保留2個.dbml文件的方法。其中一個擁有Stored Procs，所有生產數據庫訪問均通過此操作完成。另一個位於單元測試文件夾中，用於保存表格及其關係，用於DB數據操作和查詢單元測試。
超過一定的大小可能會更容易與xml而不是dbml設計器一起工作。
利用名稱空間設置。您可以通過單擊ORM的空白區域來獲取屬性。
這使我可以爲一組業務規則創建一個Users表和一個User類，爲另一組業務規則創建另一個（但是相同的數據存儲）Users表和一個User類。
或者分解庫，根據公司的命名規則，這也應該改變命名空間的影響。我從來沒有在需要訪問每個表的企業應用程序上工作。
我已經編寫了一個實用程序來解決這個問題，我需要一個快速的應用程序讓您只選擇您需要的數據庫對象。在我的情況下，我經常需要複雜的視圖，但沒有表格。
我寫了一個工具呢！我是用腳本對使用c＃的dbml文件進行腳本更改，以便可以重新運行它們而不會丟失更改。看我的博客http://www.adverseconditionals.com 4更多詳情
博客似乎失望。 – 2009-08-11 14:57:18
該鏈接不適合我.... – 2008-11-19 15:36:15