我可以从实体抽象实体框架吗？ [英] Can I abstract Entity Framework away from my Entities?

问题描述

我在实体框架中有一个 Foo 实体。但是我正在使它继承自 IFoo ，以便我的业务逻辑只知道 IFoo - 从而抽象实体框架。

I have a Foo entity in Entity Framework. But I'm making it inherit from IFoo so that my business logic only knows IFoo - thus abstracting Entity Framework away.

问题是 Foo 有一个集合 Bar 实体。此集合的类型为 EntityCollection< Bar> 。

The problem is that Foo has a collection of Bar entities. And this collection is of type EntityCollection<Bar> .

如果我将这个集合放在 IFoo 中，那么我就会使 IFoo 依赖于实体框架。所以我想把它当成 ICollection< IBar> ，但是这并不是编译（自然）。

If I put this collection in IFoo as it is, I make IFoo dependent on Entity Framework. So I thought of putting it as ICollection<IBar>, but this doesn't compile (naturally).

我可以想到的唯一的解决方案是去实体框架设计器生成的具体的 Foo 实现，并从 EntityCollection< Bar> 到 ICollection< IBar> 那里。但是我对这个对实体框架幕后的含义感到恐惧。

The only solution I can think of is to go to the concrete Foo implementation generated by the Entity Framework designer and change the collection from EntityCollection<Bar> to ICollection<IBar> there. But I dread the thought of the implications this will have on Entity Framework "behind the scenes".

有没有办法定义 IFoo 和 IBar 独立于实体框架，同时仍然维护 Foo 和作为实施它们的EF实体的Bar ？如果我无法实现我的目标的这种独立性，那么就可以实现 IFoo 和 IBar

Is there any way for me to define IFoo and IBar independently of Entity Framework while still maintaining Foo and Bar as EF Entities that implement them? Do IFoo and IBar even make sense, if I cannot achieve this independence that I aim for?

推荐答案

您所指的一般概念是持久性无知（PI），尽管它通常直接适用于实体本身，而不是消耗的代码实体。

The general concept you are referring to is "persistence ignorance" (PI), although that generally applies directly to entities themselves rather than the code that consumes the entities.

无论如何，Hibernate和NHibernate本身支持PI，但Microsoft的Entity Framework的初始版本不支持。 MS获得了很大的收获，PI可能是下一个版本的第一大讨论功能（每当这样）。

In any case, Hibernate and NHibernate natively support PI, but the initial version of Microsoft's Entity Framework does not. MS caught a lot of flak for this and PI is probably the #1 most discussed feature for the next version (whenever that is).

就你所试图与接口有关，在检索到Bars的集合是否需要修改后？如果答案是肯定的，那就没有简单的答案。即使协方差也不能帮助你，因为 ICollection< T> 有一个Add方法。

As far as what you are trying to do with interfaces, does the collection of Bars need to be modified after it is retrieved? If the answer is yes, there is no easy answer. Even covariance couldn't help you here because ICollection<T> has an Add method.

只读，那么你可以考虑将它暴露为 IEnumerable< IBar> 。 Enumerable.Cast 方法使此方法相当方便。

If the collection is read-only, then you might consider exposing it as IEnumerable<IBar>. The Enumerable.Cast method makes this fairly convenient.

interface IFoo
{
    IEnumerable<IBar> Bars { get; }
}

partial class Foo : IFoo
{
    IEnumerable<IBar> IFoo.Bars
    {
        get { return Bars.Cast<IBar>(); }
    }
}

另外，我知道至少一个努力使当前版本的EF支持持久化无知。

Also, I know of at least one effort to make the current version of EF support persistence ignorance.

这篇关于我可以从实体抽象实体框架吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！