4

我正在使用实体框架代码优先创建一个应用程序，并且在遵循接口隔离原则的同时，我面临着一些 EF 限制的问题。 UML 中的应用程序模型架构的一部分

    public interface IProduct
{
    int Id { get; set; }
    ICollection<IProcess> Processes { get; set; }
    ICollection<ILine> Lines { get; set; }
    String Description { get; set; }
    String Number { get; set; }
    String Name { get; set; }
}

问题是 Processes 和 Lines 属性导致它无法确定具体类型中的哪个类（我想）。

我知道我可以通过使用抽象类来实现几乎相同的效果。我之所以没有这样做，是因为我发现由于 EF 限制而更改模型是错误的。

解决这个问题的最佳方法是什么？任何允许接口作为导航属性的 EF 替代方案。

4

2 回答 2

3

只有一种方法可以解决这个问题——使用持久化到数据库的具体类。EF 不支持任何其他方式。除非您映射整个继承树（不要那样做），否则即使使用抽象类也无济于事。

如果您希望属性公开接口，则必须提供第二个非映射属性，该属性将在内部从公开具体类型的属性进行转换。

简单地说，如果您想使用 EF，您必须弯曲您的架构以遵循其功能集。

于 2012-01-20T09:40:40.493 回答
0

我知道这是一个旧线程，但如果其他人遇到它，我有一个更好的解决方法来使用 EF。

基本上我有两个接口

public interface IProduct
{
    int Id { get; set; }
    String Description { get; set; }
    String Number { get; set; }
    String Name { get; set; }
}

和

public interface IEFProduct
{
    ICollection<IProcess> Processes { get; set; }
    ICollection<ILine> Lines { get; set; }
}

我将IProduct接口保留在我的合同项目中，因此它仍然完全独立于我的模型的其余部分，但我将IEFProduct接口放在我的模型项目中，因为它包含具体的实现。这意味着我无法从实现接口而不是具体类型的任何东西访问进程和行，但就我而言，它让我解决了这个问题。

另一种方法是使用 DTO。

您的模型都将使用该接口，但您的实际 EF 实现将使用具体 DTO，在数据层中您将手动或使用 Automapper 在它们之间进行映射 - 当然这可能会对性能产生轻微影响。

于 2014-07-08T09:17:56.807 回答