19

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

Ladislav Mrnka
  • 349,807
  • 56
  • 643
  • 654
oliver.sakkam
  • 201
  • 2
  • 5
  • [OT] you can also use NHibernate, and you won't have to make tradeoffs :-) – Diego Mijelshon Feb 23 '11 at 12:37
  • @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 Feb 23 '11 at 16:48
  • @Yakimych: with NHibernate, your choice of a mapping method and tools does not limit the available features. – Diego Mijelshon Feb 23 '11 at 17:33
  • @Diego: Unfortunatelly sometimes you have to deal with stupid company polices which say: No NHibernate, No open source, etc. – Ladislav Mrnka Feb 24 '11 at 21:23
  • @LadislavMrnka: there's always http://careers.stackoverflow.com :-) – Diego Mijelshon Feb 24 '11 at 21:28

1 Answers1

18

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.

Ladislav Mrnka
  • 349,807
  • 56
  • 643
  • 654
  • You've hit all the points I would put in my answer. I would only add weight to the comment "not very good for big models". 50 tables is not a big model, but you're absolutely right it really goes pear shaped around 50. And it's an nightmare in a multi-developer environment. I've started using CTP5, even given the cons, because I suspect they will be done long before I am, and the current thinking is that ctp5 is the final release before it's nailed down. – Ralph Shillington Feb 23 '11 at 10:20