2012-06-06 59 views
2

我们的团队正致力于通过广泛的现有数据库模式实现代码优先的EF框架。我们真正想要的一件事就是我们所有不同实体都将实施的基础接口。我们打算在此基本界面中定义的所有内容是Id字段和名称字段,因为我们所有的数据库表都具有这两个属性的某些概念。这种方法有很多好处,因为在我们的应用程序中有很多情况下,你需要的所有对象都是它的Id和一些描述性文本(它的'Name'),因此能够编程到接口而不是该实现可以提供相当多的灵活性。具有基本实体类的实体框架

问题的产生是因为我们的模式中并不是所有的表都具有基于整数的PK,有的具有字符串,GUID等。因此,我们无法为接口中的Id字段定义真正的“类型”,除此之外可以容纳所有可能性的对象。接下来的问题是EF不喜欢把对象作为它的PK的想法,所以它在试图指定HasKey(o => o.Id)时抱怨。

无论如何,你们可以想到完成我们试图在这里拉扯什么?谢谢!

回答

5

使用泛型。

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 
+0

确定的,但随后的界面迫使你TKEY的类型......所以承担,我改变你的界面不使用TKEY的片刻,使类型'对象'的Id。然后,我可以简单地传递该接口的集合,例如:列表。但是在你的实现中,我不能这样做,我必须选择我想要传递的类型:List >或List >等等。这种方式打败了目的,因为你必须知道什么基础类型是在那种情况下为什么有一个接口? – snappymcsnap

+1

你是说你要制作一个包含多种类型对象的列表?这是什么用例?你会如何对它进行比较?或者你是否担心有一个共享方法返回可以与任何类型一起使用的实体列表?您可以使该方法通用以解决问题。 – cadrell0

+0

也许你可以修改这个问题来包含一些你想要如何使用它的例子代码。 – cadrell0