Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

EF POCO code only VS EF POCO with Entity Data Model

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

like image 777
oliver.sakkam Avatar asked Feb 23 '11 02:02

oliver.sakkam


People also ask

What is the difference between POCO code first and simple EF approach?

If you use EF code first you have POCO objects and the database is created with code from the DbContext class. You get no visual designer when using code first. You can also use POCOs for “ordinary” EF but then your database will be handled by an edmx file and a visual designer.

What is POCO in Entity Framework?

POCO Entities (Plain Old CLR Object) A POCO entity is a class that doesn't depend on any framework-specific base class. It is like any other normal . NET CLR class, which is why it is called "Plain Old CLR Objects". POCO entities are supported in both EF 6 and EF Core.

How many types of EF are there?

There are three approaches to model your entities in Entity Framework: Code First, Model First, and Database First. This article discusses all these three approaches and their pros and cons.

What is entity data model?

The Entity Data Model (EDM) is a set of concepts that describe the structure of data, regardless of its stored form. The EDM borrows from the Entity-Relationship Model described by Peter Chen in 1976, but it also builds on the Entity-Relationship Model and extends its traditional uses.


1 Answers

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.

like image 109
Ladislav Mrnka Avatar answered Nov 16 '22 03:11

Ladislav Mrnka