2012-06-07 70 views
2

我在使用EF Code First模擬圖結構時遇到了一些麻煩。我有一種情況,我的應用程序中的許多具體對象可以是與任何類型的邊緣相關的節點。在EF中建模有向圖CF

例如,兩個用戶對象可具有關係(喜歡,不喜歡,有關),但是每個可同樣涉及到另一種類型的對象(「觀察」頁上,「喜歡」的消息等)

爲了在應用程序中對此進行建模,我使用了GraphNode的基類,所有可能的節點都將繼承基類,並且每個GraphNode都有一個邊集合。每個邊都有一個SourceNode,一個DestinationNode和一個RelationshipType(用於加權)。

我知道我將如何將它建模爲數據庫優先開發,Edge的表有一個代理鍵,SourceObjectID和DestinationObjectID字段,它們是來自被鏈接對象的PK,SourceObjectType和DestinationObjectType字段這是相關對象的類型,但該網站需要EF Code First實施。

我已經知道了我正在使用TPT繼承,所以我有一個GraphNode表,其中有一個PK是GraphNodeID,但它隨後將它用作每個表的PK具體的類型,而不是他們自己的將會導致問題的PKs。

有沒有人做過這個,或者任何人都可以指出我正確的方向來做到這一點?

回答

0

正如你發現的那樣,繼承並不適合這種情況。

其他ORM如NHibernate爲「異構關聯」提供了開箱即用的支持。由於EF沒有,我的解決方案是在「服務」層(即在控制器/視圖模型和DbContext之間)處理這個問題。

我所做的是創建一個抽象,讓我存儲和檢索與任何實體關聯的元素(在我的情況下,Notes或Comments)。我通過手動存儲引用對象的實體類型和ID來完成此操作。

這是當你要與非尚未持久化實體的元素相關聯,除了大部分是微不足道的(我處理,使用我的DbContext一些回調)

+0

聽起來差不多就是我終於實現了。它可能不如我所希望的那麼優雅,但它確實是我知道工作的一種模式。我將選擇一種無節點版本,所以我的EF實體只是Edge,具有SourceID,SourceType,DestinationID,DestinationType和RelationshipType,並且如您所建議的那樣,我必須處理根據指定類型和Id進行選擇而遠離數據庫的關係。 –