2011-01-27 75 views
3

Linq-to-sql類爲父級引用了一個子集合,同時子級也引用了父級(單個或集合)。這允許一個「鑽」在兩個方向,並且看起來相當方便。業務對象(層次結構)之間的循環引用常見嗎?

這是一個適用於手動創建業務對象(PO​​CO或其他)的設計嗎?以防萬一;什麼是優點/缺點,或特定的情況下,這將建議?


EDIT1:

我想主要講邏輯驅動行爲;這意味着不是用戶交互,而是像處理金融交易,遊戲軟件等的程序一樣。如果您處理子實體,然後需要其父項的某些參數,該怎麼辦?這似乎很方便,但也許這是我的編碼習慣的其他部分是問題,並讓我覺得我需要這個..

回答

0

是的,雙向引用是常見和有用的。它們在面向對象的體系結構中非常有效。您指出的優點如下:它們可以幫助您爲域對象建模,並有效地遍歷所述對象。從消極的角度來看,它們可能會讓您更難理解您的代碼,因爲有更多的信息流通途徑。

但是不要太擔心試圖安撫RDMS神......很可能它不會引起底層數據存儲的問題,並且在一天結束時,您必須假設您的地圖繪製技術將會提出一種中途體面的地圖繪製策略,或者您應該將其替換爲其中的一種。

2

不知道這是否真的是你正在尋找的答案,但這裏是我的2美分。

循環參考是一個可怕的數據庫設計,應該不惜一切代價避免。

由於無法預先確定操作的順序,並且高度依賴於記錄中包含的數據,所以它使得對批量記錄的系統插入和刪除幾乎不可能實現。

這方面的一個例子是這樣的:

class Company 
{ 
    Person ContactPerson {get;set;} 
} 

class Person 
{ 
    Company Company {get;set;} 
} 

你從字面上有一個趕上22日(或雞有蛋的問題),這裏的情況與數據庫打交道時。

但是,在代碼中處理它並不是什麼問題。

+0

這將如何影響數據庫設計?並非所有具有循環引用成員的L2S類中都表示標準數據庫關係? – bretddog 2011-01-27 08:15:44

+0

@bretddog:對於這樣的表格,L2S會產生相當混亂的東西。但我認爲你的意思是別的。正如我所指出的,不是真正的循環引用。 – leppie 2011-01-27 08:18:48

+0

是的,也許我的描述可能會被誤解,idk。因爲你說「這樣的桌子」,我不是指任何特殊的桌子。我的意思是你如何根據完全標準的表格/關係設計你的POCO。 – bretddog 2011-01-27 08:32:08

1

從父對象引用子集的集合是應儘可能避免的東西。如果收藏總是可能會很小,那麼你可能會放棄收藏。但是,如果收集量很大,則必須處理避免性能問題。

在決定添加從父母到孩子的引用之前,您應該考慮您的功能需求。通常可以根據父代的id爲子代進行查找。在許多應用程序的集合大小很大時,您可能會使用分頁來檢索完整集合的一部分。

+0

我在想主要是關於邏輯驅動的行爲;這意味着不是用戶交互,而是像處理金融交易,遊戲軟件等的程序一樣。如果您處理子實體,然後需要其父項的某些參數,該怎麼辦?這似乎很方便,但也許這是我的編碼習慣的其他部分是問題,並讓我覺得我需要這個.. – bretddog 2011-01-27 08:26:14

0

對於內存實體,雙向導航可以非常方便。 然而,這種持續的時候,特別是提出了問題:在RDBMS

  • 寄存 - 按Leppie。 對於一對多關係, 父FK存儲在Child 記錄中。對於一對一的 關係,將關係 另存爲FK,但只有 單程。
  • 跨線串行化可能會導致嚴重的頭痛。 通常,在一對多關係中,子項在父項下嵌套 (關係由層次結構保存)。但是,如果 子實體具有對 的引用,則父實體 引用通常不會被標記爲 ,因爲是遞歸(循環)。 (PreserveObjectReferences儘管WCF 3.5+現在已經通過(IsReference = true)解決了這個問題)。

無論哪種方式,雙向關係引用需要在從存儲/反序列化中重新水化圖形之後「修復」。 (看看由Linq2Sql生成的代碼)