Menu
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
777
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.
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.
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.
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.
It is just a matter of choice.
EFv4 with designer
Pros:
Cons:
EF code first
Pros:
Cons:
Currently I'm using the first approach. After final release I will be probably more happy with code first.
109
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
