实体框架6.0实现与POCO的实现

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

I've done this a few times. If you want your classes to be entirely separate, free from anything specific to Entity Framework, then you'll have to make a few small changes. Here's what I did:

• Create classes to represent domain entities. I did this in a completely separate assembly (for various reasons) but you don't have to.
• Reference the namespace(s) with your classes in and add sets for them to the DbContext as normal.
• Use Entity Framework's Fluent Configuration API to map your types and their relationships .

That last part means you may not be able to use attributes like [ForeignKey] , as many of them live in System.Data.Entity and at that point you're using Entity Framework stuff so you might as well just accept the coupling.

This does mean you'll have to do a little more work to set up the relationships, but it's not too bad, and when you're done your domain classes are entirely separate from Entity Framework, allowing you to mock it for testing or swap it for another ORM pretty painlessly.

Answer 2

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.

Answer 3

You don't want to create interfaces for your entities, as you'll end up with header interfaces as you have here, and therefore the interfaces are not abstractions at all and have little value. If you create role interfaces then you can easily stub out the implementations in tests to return the entities you wish.