EF POCO code only VS EF POCO with Entity Data Model

19
votes

The ability to separate domain objects completely from any kind of persistance code makes systems much more extensible and maintainable. Testing is made much easier when business logic can be tested separately from storage code. The use of POCOs with the Entity Framework (EF) is definitely a step in the right direction :)

there are 2 types of using poco with EF 1.Using the entity designer 2.Using the code only

which one is the best approach EF poco code first or EF Poco using the entity data model designer ?

thanks

1
entity-frameworkentity-framework-4pocoef-code-first
[OT] you can also use NHibernate, and you won't have to make tradeoffs :-) – Diego Mijelshon
@Diego: Just curious - what exactly are you implying? As far as I remember, nHibernate allows to define mappings in xml, as well as in code (fluent nHibernate) - basically same options as in EF. So what tradeoffs are you talking about avoiding? – Yakimych
@Yakimych: with NHibernate, your choice of a mapping method and tools does not limit the available features. – Diego Mijelshon
@Diego: Unfortunatelly sometimes you have to deal with stupid company polices which say: No NHibernate, No open source, etc. – Ladislav Mrnka
@LadislavMrnka: there's always careers.stackoverflow.com :-) – Diego Mijelshon

1 Answers

18
votes

It is just a matter of choice.

EFv4 with designer

Pros:

  • You have designer support and T4 template which will generate entities for you = RAD.
  • You have very big feature set including support for views, stored procedures mapping and some custom model defined objects like QueryView or Model defined function.
  • Support for other EF types when needed (Self tracking entities, Entity objects).

Cons:

  • Designer is not very good tool for big models (50+ tables)
  • Not all features are supported in designer - you must access EDMX as XML
  • EDMX XML structure is probably the most complex and hard to understand description among all available .NET ORM tools
  • Working in shared environment with designer is just a pain - it is better to use exclusive locks on EDMX
  • Edit: I forgot my very popular drawback. Designer stores all mapping data in EDMX together with its own data about positioning entities in diagram. Even such stupid action like zooming diagram will check out the EDMX file from source control.

EF code first

Pros:

  • Ability to define everything in code
  • Attribute based mapping and Fluent API
  • Some very nice API features - conventions, Local, etc.
  • I think this API is less complex and easier to use

Cons:

  • It is not final release yet. Current release is only community technology preview 5.
  • Because of that API can change in final release.
  • You must write all code by yourselves.
  • Feature set is limited compared to "big" EF.
  • There is no documentation, currently you will have to look for information in blogs.

Currently I'm using the first approach. After final release I will be probably more happy with code first.