如何覆蓋默認的LINQ to SQL關聯名稱

我正在使用LINQ to SQL進行數據庫訪問的非常直接的C＃應用程序。該應用程序是一個非網頁（即胖客戶端）應用程序。如何覆蓋默認的LINQ to SQL關聯名稱

我最近碰到的問題是LINQ to SQL爲外鍵到另一個表的字段創建的默認關聯名稱。更具體地說，我提供了一個例子如下：

問題示例我的大多數組合框都是使用來自存儲類型，描述和一些其他字段的引用數據表（即RefData）中的值填充的。最初加載表單時，它會根據類型查詢填充組合框。例如，我有一個允許用戶添加客戶的表單。在這個表格中，有一個狀態組合框。通過對type = stateType的RefData表運行查詢來填充stateComboBox。然後，當用戶以選定狀態保存客戶時，所選狀態的RefData列的ID存儲在客戶表的狀態列中。所有這些都按預期工作。但是，如果我的客戶表有多個列作爲RefData表的外鍵，那麼它很快會變得非常混亂，因爲由LINQ創建的關聯名稱是Customer.RefData，Customer.RefData1，Customer.RefData2等。 ..如果我可以覆蓋關聯的名稱，以便訪問參考數據將更像Customer.State，Customer.Country，Customer.Type等等，這將會容易得多...

我看過在由VS生成的DBML中更改此信息，但是，我的數據庫模式仍然非常不成熟並且不斷需要更改。現在，我一直在每天或兩天刪除DBML，以便在更改數據庫後重新生成LINQ to SQL文件。有沒有一種簡單的方法來創建這些關聯有意義的名稱，而不會丟失，而我經常重新創建DBML？

來源

2012-02-06 Grasshopper

我不確定LINQ to SQL是訪問數據的最佳方法，但是我發現它在您的情況下更成問題。

您真正的問題是您的域對象的概念相當靜態（您知道該程序需要用來完成工作），但是您不確定如何保持數據，因爲您的模式位於通量。對於automagic更新，這不是一個好方案。

如果是我，我會對領域模型進行編碼，以便除非您希望更改，否則不會更改。然後我將確定如何鏈接到持久性模式（在這種情況下爲數據庫）。如果你喜歡更多的automagic，那麼我會考慮實體框架，因爲你可以先使用代碼並在模式發生變化時映射到該模式。

如果您發現這仍然沒有幫助，因爲您的數據庫架構更改與域模型不兼容，您需要遠離編碼並進入更深層次的規劃模式。否則，你將繼續在變化的諺語牆上擊敗你的頭。

來源

2012-02-06 18:42:47

謝謝，我簡要介紹了實體框架，因爲我們在這裏有一個開發人員將其用於移動網站。我可能誇大了領域模型改變的頻率。所有的域對象都有相當明確的定義，但是，我繼承了這個項目並且給了一個非常激進的截止日期。最終，我主要需要對某些列的數據類型進行微調，並在必要時添加外鍵。我對LINQ和.NET相當陌生，並確信有更好的設計。現在，我正在使用存儲庫模式與DAOs – Grasshopper 2012-02-06 18:51:00

@Grasshopper：存儲庫是一個體面的模式，但我genreally喜歡鞏固我的領域模型和地圖，而不是使用automagic LINQ to SQL位進行映射。有一些可愛的方法（在某些情況下是kludges）來重寫部分類中的某些位，以便regen打破部分類（不會編譯），而不是擰緊您的域模型，所以LINQ to SQL有很多方法。無論你是否誇大了這個改變，這顯然是一個痛點，當你有很多代碼依賴於特定的命名，而且automagic會讓它變得更糟時，這是很常見的。 – 2012-02-06 18:59:56

謝謝，我現在回到域模型。我曾經使用Java和Hibernate來手動創建映射文件。我已經想出瞭如何命名其他表格的引用，但是，我認爲我最關心的問題是這是否是最優雅的設計，並且擔心隨時必須更改數據庫，以至於自動生成將導致大量對映射文件的重新工作量。 – Grasshopper 2012-02-06 19:14:15

如何覆蓋默認的LINQ to SQL關聯名稱

回答

相關問題