Entity Framework 6.0 Decoupling Implementing From POCOs

Question

Lets say I have a couple basic objects and interfaces for them:

interface ICar
{
  int Id { get; set; }

  int DriverId { get; set; }

  IDriver Driver { get; set; }
}

class Car: ICar
{
  int Id { get; set; }

  [ForeignKey("Driver")]
  int DriverId { get; set; }

  IDriver Driver { get; set; }
}

If I use the implementing class of "Driver" instead of "IDriver" everything is happy (so lets ignore I'm missing additional configuration for all the other values), however using IDriver ends up with the error:

The property 'Driver' cannot be configured as a navigation property. The property must be a valid entity type and the property should have a non-abstract getter and setter. For collection properties the type must implement ICollection where T is a valid entity type.

So far as I understand it entity doesn't actually support this in any way, my options are:

• Hard couple my POCO interfaces to entity, throwing a wrench into testability and portability, welp.
• Add a transition layer between my POCOs and entity objects (bleh).
• Throw entity out, sort of work around this with some nasty Linq2SQL implementations that sort of support this (though Linq2SQL complains about EntityRefs, it plays fine with EntitySets and interfaces!).
• Find another ORM that will allow me to properly abstract my POCOs from my implementing data provider.

Or am I missing something here?

Answer 1

You are not coupling POCOs to EF, it's the other way around and totally legitimate since domain objects are basic building blocks of your application. Similar to ints, strings, etc... You would not "interface" int, would you? At any time you throw EF away and take NH, for example, this would not affect your POCOs at all.

Now, custom DbContext and business classes on the other hand ARE the things you need to create interfaces for. This way you can mock them for test purposes and change implementations.

And one more thing - do not trap yourself with the idea of abstracting EF from the business layer in a self written data access layer. Although, this is achievable, it also puts tons of restrictions on your business layer implementations. You'll have to invent self torturing techniques to write queries which would take 5 seconds of your time otherwise.

In my opinion, the ideal dependency diagram, I came up with after a lot of experiments, now looks like this

Domain objects, business and context interfaces are the core of the app. Other layers are independent of each other and therefore testable.

Be mindful thought, that business layer here is dependent on EF and if I ever decide to switch from EF (highly doubt it) I will have to port my business classes. This, I believe, is a very unlikely event and a small price to pay for all the comfort EF gives me in my business classes.