c# - Entity Framework 6.0 Decoupling Implementing From POCOs -


lets have couple basic objects , interfaces 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 use implementing class of "driver" instead of "idriver" happy (so lets ignore i'm missing additional configuration other values), using idriver ends error:

the property 'driver' cannot configured navigation property. property must valid entity type , property should have non-abstract getter , setter. collection properties type must implement icollection t valid entity type.

so far understand entity doesn't support in way, options are:

  • hard couple poco interfaces entity, throwing wrench testability , portability, welp.
  • add transition layer between pocos , entity objects (bleh).
  • throw entity out, sort of work around nasty linq2sql implementations sort of support (though linq2sql complains entityrefs, plays fine entitysets , interfaces!).
  • find orm allow me abstract pocos implementing data provider.

or missing here?

you not coupling pocos ef, it's other way around , totally legitimate since domain objects basic building blocks of application. similar ints, strings, etc... not "interface" int, you? @ time throw ef away , take nh, example, not affect pocos @ all.

now, custom dbcontext , business classes on other hand things need create interfaces for. way can mock them test purposes , change implementations.

and 1 more thing - not trap idea of abstracting ef business layer in self written data access layer. although, achievable, puts tons of restrictions on business layer implementations. you'll have invent self torturing techniques write queries take 5 seconds of time otherwise.

in opinion, ideal dependency diagram, came after lot of experiments, looks enter image description here

domain objects, business , context interfaces core of app. other layers independent of each other , therefore testable.

be mindful thought, business layer here dependent on ef , if ever decide switch ef (highly doubt it) have port business classes. this, believe, unlikely event , small price pay comfort ef gives me in business classes.


Comments

Popular posts from this blog

jQuery Mobile app not scrolling in Firefox -

c++ - How to add Crypto++ library to Qt project -

php array slice every 2th rule -