具有基本實體類的實體框架

我們的團隊正致力於通過廣泛的現有數據庫模式實現代碼優先的EF框架。我們真正想要的一件事就是我們所有不同實體都將實施的基礎接口。我們打算在此基本界面中定義的所有內容是Id字段和名稱字段，因爲我們所有的數據庫表都具有這兩個屬性的某些概念。這種方法有很多好處，因爲在我們的應用程序中有很多情況下，你需要的所有對象都是它的Id和一些描述性文本（它的'Name'），因此能夠編程到接口而不是該實現可以提供相當多的靈活性。具有基本實體類的實體框架

問題的產生是因爲我們的模式中並不是所有的表都具有基於整數的PK，有的具有字符串，GUID等。因此，我們無法爲接口中的Id字段定義真正的「類型」，除此之外可以容納所有可能性的對象。接下來的問題是EF不喜歡把對象作爲它的PK的想法，所以它在試圖指定HasKey（o => o.Id）時抱怨。

無論如何，你們可以想到完成我們試圖在這裏拉扯什麼？謝謝！

來源

2012-06-06 snappymcsnap

使用泛型。

public interface IEntityBase<TKey> 
{ 
    TKey Id { get; set; } 
    string Name { get; set; } 
}

然後你就可以實現像這樣

public class IntKeyEntity : IEntityBase<int> 
{ 
    int Id { get; set; } 
    string Name { get; set; } 
} 

public class StringKeyEntity : IEntityBase<string> 
{ 
    string Id { get; set; } 
    string Name { get; set; } 
} 

//etc

來源

2012-06-06 14:40:50 cadrell0

確定的，但隨後的界面迫使你TKEY的類型......所以承擔，我改變你的界面不使用TKEY的片刻，使類型'對象'的Id。然後，我可以簡單地傳遞該接口的集合，例如：列表。但是在你的實現中，我不能這樣做，我必須選擇我想要傳遞的類型：List >或List >等等。這種方式打敗了目的，因爲你必須知道什麼基礎類型是在那種情況下爲什麼有一個接口？ – snappymcsnap

你是說你要製作一個包含多種類型對象的列表？這是什麼用例？你會如何對它進行比較？或者你是否擔心有一個共享方法返回可以與任何類型一起使用的實體列表？您可以使該方法通用以解決問題。 – cadrell0

也許你可以修改這個問題來包含一些你想要如何使用它的例子代碼。 – cadrell0

具有基本實體類的實體框架

回答

相關問題