EF POCO code only VS EF POCO with Entity Data Model

Question

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 bus

Answer 1

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.