I'm trying to figure out if it would be possible to stick to the mantra "Program against an interface, not an implementation." while using the Entity Framework 4.0.

While I found a page explaining how to stick to aforementioned rule while using Linq-to-SQL ([look here](http://iridescence.no/post/Linq-to-Sql-Programming-Against-an-Interface-and-the-Repository-Pattern.aspx)) I'm very keen to know if it would be possible to do that with the Entity Framework (also using Linq).

This is how it is usually used:

```
var query = from pages in dataContext.Pages where pages.IsPublished select pages;

foreach (Page page in query)
{
    // do something with page...
    var routeQuery = from routes in page.Route where route.IsValid select routes;

    foreach (Route route in routeQuery)
    {
        // do something with route
    }
}

```

But I'd like to use it like this:

```
var query = from pages in dataContext.Pages where pages.IsPublished select pages;

foreach (IPage page in query)
{
    // do something with page...
    var routeQuery = from routes in page.Route where route.IsValid select routes;

    foreach (IRoute route in routeQuery)
    {
        // do something with route
    }
}

```

Essentially I would like to be able to pass the DataContext of the Entity Framework out of the assembly/subsystem where it is instanciated by using an interface. All information which is provided by the data context should come in the form of an interface, not an actual class.

I would like to keep the actual classes implementing the Entities internal to the assembly and only expose the interfaces which they implement.

Is this possible with the Entity Framework? If not, is there any other O/R mapper which can be used in this way?

If this is not a good way how to further de-couple the DB from the actual application I'd be keen to hear suggestions from you.